[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT
https://issues.dlang.org/show_bug.cgi?id=17596 --- Comment #21 from Jonathan M Davis --- This adds version identifiers for the version of FreeBSD, which will make it possible to version OS bindings for the version of FreeBSD where necessary: https://github.com/dlang/dmd/pull/8567 --
[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT
https://issues.dlang.org/show_bug.cgi?id=17596 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #20 from Jonathan M Davis --- (In reply to Vladimir Panteleev from comment #9) > Alright, so how about: > > - We add getosreldate and INO64_FIRST to druntime > - We add both the old and new struct definitions > - We add a stat wrapper which,when getosreldate() < INO64_FIRST, translates > the old struct to the new struct and returns it. I tried that with the functions from sys/mount.h that use statfs_t, and it doesn't work. The problem is that from what I can tell, if you build a program on FreeBSD 11, it runs just fine on FreeBSD 12 - at least it did with the functions in sys/mount.h. e.g. When running a program built on FreeBSD 11 on FreeBSD 12, fstatfs reports the same version with its f_version member that it does on FreeBSD 11, and it clearly calls the FreeBSD 11 version of fstafs. objdump confirms this. If you compile a C/C++ program which uses fstatfs on FreeBSD 12 and use objdump -t on it and grep for fstatfs, it has 002013e0 F *UND* fstatfs whereas if you compile it on FreeBSD 11, you get F *UND* 0011 fstatfs@@FBSD_1.0 Building a D program that does the same thing on FreeBSD 11 also results in F *UND* 0011 fstatfs@@FBSD_1.0 and it still says F *UND* 0011 fstatfs@@FBSD_1.0 if you run objdump on it in FreeBSD 12. And it runs just fine on FreeBSD 12. If I create a wrapper in druntime so that it uses the FreeBSD 11 version of stat_t if getosreldate() < INO64_FIRST, then it works just fine on FreeBSD 11 but fails miserably when running that binary on FreeBSD 12, because the binary has the FreeBSD 11 version of the function in it, and it's the FreeBSD 11 version of stat_t that it's using even though it's running on FreeBSD 12. So, from what testing I've done thus far, running D binaries built on FreeBSD 11 on FreeBSD 12 works just fine. What fails is when you try to build a program on FreeBSD 12 (including the compiler). The resulting binary doesn't work properly if it uses any of the structs that changed, because the definition in D does not match the definition in C. It may be that taking a program built on FreeBSD 11 which uses a function like fstatfs and running it on FreeBSD 12 only works because the OS itself detects which version of the function your program is built with and therefore calls the old version of the syscall internally (I don't know), but building a D program on FreeBSD 11 and running it on 12 seems to work just fine right now, whereas if you build anything with dmd on FreeBSD 12 where the definition in druntime does not match the actual FreeBSD 12 definition, then it doesn't work. So, my conclusion is that the only way to fully fix this is for the struct definitions to be versioned based on the version of FreeBSD the program is built on (which would then allow us to do the same thing that C/C++ does and have versioned headers). And arguably, assuming that there's only one version of the OS when creating bindings for the OS headers is a terrible idea to begin with. We only really get away with it like we do because of the fact that most of them don't change very often. In any case, all of the extra stuff with detecting the version of FreeBSD at runtime in D and changing which version of a struct you use based on what getosreldate() says might make it possible to run a binary built on FreeBSD 12 (with the FreeBSD 12 versions of the structs) on FreeBSD 11 (I don't know), but it breaks running a FreeBSD 11 binary on FreeBSD 12. As far as I can tell, we really only have two options: 1. Make it so that dmd actually provides a version identifier for different versions of FreeBSD (e.g. FreeBSD11 and FreeBSD12) so that we can version the definitions in druntime just like they would be in the actual C headers (since FreeBSD 11 gets different headers than FreeBSD 12). That way, we could version most stuff with FreeBSD like we always have but cleanly cope when definitions change between versions of FreeBSD by versioning those few symbols with identifiers such as FreeBSD11 or FreeBSD12. 2. Have a PR where we change all of the struct definitions that differ between FreeBSD 11 and FreeBSD 12, use a dmd binary built on FreeBSD 11 with the old code to build it, and then immediately require that everything built with that version of dmd and newer use FreeBSD 12. That's theoreticaly feasible, but it could be difficult to make work well with the auto-tester, and it would be fairly disruptive. This isn't like with Windows where we say that we support
[Issue 18788] static arrays with a length specified at runtime should dynamically allocate on the stack
https://issues.dlang.org/show_bug.cgi?id=18788
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #7 from Walter Bright ---
(In reply to Mike Franklin from comment #0)
> char[newLen + 1] buf; // Error: variable newLen cannot be read at
> compile time
I suspect the correct way to handle this would be:
scope char[] buf = new char[newlen + 1];
The `scope` will ensure `buf` does not escape the stack frame, and so the
compiler can allocate it on the stack.
This is how:
class C { ... }
scope C c = new C();
works today.
--
[Issue 19159] `alloca` does not work in -betterC
https://issues.dlang.org/show_bug.cgi?id=19159 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- alloca() works by calling a compiler-specific function to implement it. This means it has to be customized for each supported C compiler. Currently for dmd, this has only been done for dmc (Win32). Whether it's standard C or not, functions that are in the corresponding compiler's stdlib.h should be in core.stdc.stdlib. --
[Issue 17019] std.algorithm.iteration.each should be usable with parallel
https://issues.dlang.org/show_bug.cgi?id=17019 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17019] std.algorithm.iteration.each should be usable with parallel
https://issues.dlang.org/show_bug.cgi?id=17019 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/3f44a4cd73a2c6423d4a49e3354b02a4acac2dfe Fix issue 17019 - std.algorithm.iteration.each should be usable with parallel https://github.com/dlang/phobos/commit/bb769cfaf51f32a9f20567f885361fe828e9f8a3 Merge pull request #4990 from wilzbach/fix-15357-each-foreach Fix issue 17019: `each` should be usable with parallel (and behave like foreach) merged-on-behalf-of: Andrei Alexandrescu --
[Issue 19135] std.json : JSON_TYPE does not match D Style.
https://issues.dlang.org/show_bug.cgi?id=19135 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19135] std.json : JSON_TYPE does not match D Style.
https://issues.dlang.org/show_bug.cgi?id=19135 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/fbd094737fa1130ab53f7fcc17b36f8881e10790 Fix Issue 19135 Rewrite std.json.JSON_TYPE to be CamelCase with lowercase members, with underscore attached to avoid keyword collision. Deprecate the old type via alias. https://github.com/dlang/phobos/commit/a26ccc6f4cd6cac93b9361233fd093b72c09a869 Merge pull request #6649 from FeepingCreature/fix/issue-19135-rewrite-json_type-to-match-style-guidelines Fix Issue 19135: Rename std.json.JSON_TYPE to JsonType with lowercase attributes merged-on-behalf-of: Petar Kirov --
[Issue 19152] 2.081.1 getOverloads regression compiler bug
https://issues.dlang.org/show_bug.cgi?id=19152 Richard Cattermole changed: What|Removed |Added Summary|2.081.1 Regression compiler |2.081.1 getOverloads |bug |regression compiler bug --
[Issue 19152] 2.081.1 Regression compiler bug
https://issues.dlang.org/show_bug.cgi?id=19152 Mike Franklin changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #5 from Mike Franklin --- *** Issue 19170 has been marked as a duplicate of this issue. *** --
[Issue 19170] getOverloads with a pointer type seg faults (ICE)
https://issues.dlang.org/show_bug.cgi?id=19170 Mike Franklin changed: What|Removed |Added Status|NEW |RESOLVED CC||slavo5...@yahoo.com Resolution|--- |DUPLICATE --- Comment #1 from Mike Franklin --- *** This issue has been marked as a duplicate of issue 19152 *** --
[Issue 19170] New: getOverloads with a pointer type seg faults (ICE)
https://issues.dlang.org/show_bug.cgi?id=19170
Issue ID: 19170
Summary: getOverloads with a pointer type seg faults (ICE)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: alphaglosi...@gmail.com
Working up on 2.080.0, Not working as of 2.081.2.
Example:
struct Foo {
int func() {}
}
pragma(msg, __traits(getOverloads, Foo*, "func"));
Will cause an ICE.
While it is arguable that a pointer type should be supported by getOverloads,
the fact that it did work and now doesn't (while causing a very horrible and
very time consuming amount of debugging since there is effectively no useful
message e.g. location noted) means it needs fixing.
--
[Issue 19101] Miscompilation on extern(C++) overloads with D types
https://issues.dlang.org/show_bug.cgi?id=19101
--- Comment #4 from johanenge...@weka.io ---
> Not sure if a dot can be used in typenames for C++ mangling.
Good point. `a.A` should not be mangled as `a::A` (using the C++ namespace
divider), because that then would clash with C++ types.
I think it is OK if the mangle can never be expressed in C++ when there are D
types involved, because C++ cannot express the D types anyway. What I mean is,
`foo!A` should be expressible in C++:
```
extern(C++) struct A {}
extern(C++) int foo(T)(T t) {}
```
but doesn't have to in this code:
```
struct A {}
extern(C++) int foo(T)(T t) {}
```
So C++ doesn't have to be able to express the mangled name, but it would
definitely be nice if C++ demanglers can demangle it into something sensible. A
dot is actually allowed in symbol names, so we can use it as part of the name?
(i.e. pretend that the class name of A is "a.A".)
--
[Issue 19101] Miscompilation on extern(C++) overloads with D types
https://issues.dlang.org/show_bug.cgi?id=19101 --- Comment #3 from ki...@gmx.net --- (In reply to johanengelen from comment #2) > Currently we mangle extern(D) types as if they are extern(C++) types for > extern(C++) templated functions. Ah now I get it, I overlooked that the 2 structs are extern(D). [The function doesn't need to be templated.] Not sure if a dot can be used in typenames for C++ mangling. Also not sure how much code that would break (structs needing `extern(C++)` for C++ interop, whereas that's optional now). --
[Issue 19152] 2.081.1 Regression compiler bug
https://issues.dlang.org/show_bug.cgi?id=19152 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19152] 2.081.1 Regression compiler bug
https://issues.dlang.org/show_bug.cgi?id=19152 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/9b637fc660c5f2e6610d0f967334f046eb4bdad7 Fix Issue 19152 - 2.081.1 Regression - Seg fault in traits.d https://github.com/dlang/dmd/commit/5445a8234ed3688f73dd137ab79ce68f54598326 Merge pull request #8553 from JinShil/fix_19152 Fix Issue 19152 - 2.081.1 Regression - Seg fault in traits.d --
[Issue 19101] Miscompilation on extern(C++) overloads with D types
https://issues.dlang.org/show_bug.cgi?id=19101
--- Comment #2 from johanenge...@weka.io ---
> Assuming you suggest mangling `module mod; extern(C++) class C {};` as
> `mod::C`
No, of course not.
I suggest mangling `module mod; class C {};` as `mod.C`. Currently we mangle
extern(D) types as if they are extern(C++) types for extern(C++) templated
functions. In the original example, we currently mangle `foo!(a.A)(a.A)` as
`foo!(A)(A)`. Hence the miscompilation / clash with mangling of
`foo!(b.A)(b.A)`.
--
[Issue 19169] [betterC] bogus TypeInfo error for `enum string[] a = ["a"]; auto aa = a;`
https://issues.dlang.org/show_bug.cgi?id=19169
--- Comment #5 from Nicholas Wilson ---
extern(C) void main() {
immutable a = [1];
}
works fine though.
--
[Issue 19169] [betterC] bogus TypeInfo error for `enum string[] a = ["a"]; auto aa = a;`
https://issues.dlang.org/show_bug.cgi?id=19169
--- Comment #4 from Nicholas Wilson ---
This triggers for ints as well.
extern(C) void main() {
auto a = [1];
}
same problem.
--
[Issue 19169] [betterC] bogus TypeInfo error for `enum string[] a = ["a"]; auto aa = a;`
https://issues.dlang.org/show_bug.cgi?id=19169 --- Comment #3 from Nicholas Wilson --- At the very least the error message should not suck. --
[Issue 19169] [betterC] bogus TypeInfo error for `enum string[] a = ["a"]; auto aa = a;`
https://issues.dlang.org/show_bug.cgi?id=19169 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #2 from Mike Franklin --- The problem is here: https://github.com/dlang/dmd/blob/48726c875fbfe16fd93051570d149e893d2dc3dc/src/dmd/e2ir.d#L5047-L5050 --- // call _d_arrayliteralTX(ti, dim) e = el_bin(OPcall, TYnptr, el_var(getRtlsym(RTLSYM_ARRAYLITERALTX)), el_param(el_long(TYsize_t, dim), getTypeInfo(ale.loc, ale.type, irs))); --- The compiler is generating a call to `_d_arrayliteralTX` in druntime: https://github.com/dlang/druntime/blob/9a8edfb48e4842180c706ee26ebd8edb10be53f4/src/rt/lifetime.d#L2279 That runtime hook requires a `TypeInfo` parameter. One solution would be to replace `_d_arrayliteralTX` with a template and a compile-time type parameter, but this issue does beg the question why it is even calling `_d_arrayliteralTX` in the first place. --
[Issue 17707] unimported modules in libraries do not have their module constructors run
https://issues.dlang.org/show_bug.cgi?id=17707 --- Comment #1 from John Colvin --- The same behaviour is observed when the library is made with dmd, when the linking is done with dmd, etc... Essentially dmd seems to be doing something different with the __modctor it gets from an object file or a library --
[Issue 13121] std.algorithm.joiner should return a bidirectional range if possible
https://issues.dlang.org/show_bug.cgi?id=13121 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/e34f420ff1e52860772e2532fc73dcf6f8d47eb9 Fix Issue 13121 - std.algorithm.joiner should return a bidirectional range if possible https://github.com/dlang/phobos/commit/f67c43d93de14fd888387d8d33c862d522e0b8ec Merge pull request #6115 from wilzbach/13121 Issue 13121 - std.algorithm.joiner should return a bidirectional range if possible --
[Issue 13121] std.algorithm.joiner should return a bidirectional range if possible
https://issues.dlang.org/show_bug.cgi?id=13121 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19169] [betterC] bogus TypeInfo error for `enum string[] a = ["a"]; auto aa = a;`
https://issues.dlang.org/show_bug.cgi?id=19169
--- Comment #1 from Nicholas Wilson ---
Interestingly
enum a = ["a"];
__gshared auto aa = a;
extern(C) void main() {}
Passes compilation just fine.
--
[Issue 19169] New: [betterC] bogus TypeInfo error for `enum string[] a = ["a"]; auto aa = a;`
https://issues.dlang.org/show_bug.cgi?id=19169
Issue ID: 19169
Summary: [betterC] bogus TypeInfo error for `enum string[] a =
["a"]; auto aa = a;`
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: iamthewilsona...@hotmail.com
extern(C) void main() {
enum string[] a = ["a"];
auto aa = a;
}
> onlineapp.d(3): Error: TypeInfo cannot be used with -betterC
--
[Issue 19167] Overzealous "Using this as a type is deprecated"
https://issues.dlang.org/show_bug.cgi?id=19167
--- Comment #3 from ag0aep6g ---
(In reply to John Colvin from comment #2)
> How about this, which the compiler is OK with:
>
> struct A
> {
> alias a = int;
> }
>
> struct B
> {
> A a;
> alias b = a.a;
> }
>
> I don't understand the logic that says we can't directly access compile-time
> members of `this` at struct scope but we can access compile-time members of
> member variables.
I think you're right. If we can use `a` that way, we should be able to use
`this`, too. There's also this:
struct A
{
enum a = 1;
enum b = this.a; /* no deprecation */
}
So DMD doesn't reject all cases of `this`. If the enum is acceptable, the alias
in the original snippet should be acceptable, too.
--
[Issue 19167] Overzealous "Using this as a type is deprecated"
https://issues.dlang.org/show_bug.cgi?id=19167
John Colvin changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #2 from John Colvin ---
How about this, which the compiler is OK with:
struct A
{
alias a = int;
}
struct B
{
A a;
alias b = a.a;
}
I don't understand the logic that says we can't directly access compile-time
members of `this` at struct scope but we can access compile-time members of
member variables.
--
[Issue 14001] Optionally @nogc std.random.randomCover
https://issues.dlang.org/show_bug.cgi?id=14001 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14001] Optionally @nogc std.random.randomCover
https://issues.dlang.org/show_bug.cgi?id=14001 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/3a212c0c72b7177a51dde9d4bbb5bbb5a9254a35 Fix Issue 14001 - Optionally `@nogc` std.random.randomCover Fix Issue 19156 - `@nogc` std.random.randomShuffle Solution is to use a private `_randomIndex` function that is guaranteed to be called only with valid bounds. https://github.com/dlang/phobos/commit/91c9973d72a7f1ad3d958f226508520d257f9ce7 Merge pull request #6657 from n8sh/std-random-14001-19156 Fix Issue 14001 & Issue 19156 - `@nogc` std.random.randomCover and std.random.randomShuffle --
[Issue 18743] ConditionalExpression and AssignExpression should require parentheses
https://issues.dlang.org/show_bug.cgi?id=18743 --- Comment #8 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/fe4dd55a8a1f486d4db6f93b5fcc72a009367f36 Issue 18743 - ConditionalExpression with AssignExpression requires parens https://github.com/dlang/dlang.org/commit/18f70c41be54488a1e2460ef0376d6fada21 Merge pull request #2366 from ntrel/cond-assign Issue 18743 - ConditionalExpression with AssignExpression requires parens --
[Issue 19167] Overzealous "Using this as a type is deprecated"
https://issues.dlang.org/show_bug.cgi?id=19167
ag0aep6g changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||ag0ae...@gmail.com
Resolution|--- |INVALID
--- Comment #1 from ag0aep6g ---
In the first case, there is no `this` object, so DMD interprets it to mean the
type of `this`. That's been deprecated.
In the second case, there is an `a` object. The alias is still the same as
`typeof(a).a`, but that's ok. Making the alias has not been deprecated. The
deprecation is about using `this` where there is no object `this`.
Similarly, you can still use `alias b = this.a;` inside a method:
struct A
{
alias a = int;
void m()
{
alias b = this.a; /* no deprecation */
}
}
I'm closing this as invalid. As usual, feel free to reopen if I missed
something.
--
[Issue 7067] std.random.RandomSample and RandomCover are poorly designed
https://issues.dlang.org/show_bug.cgi?id=7067 Nathan S. changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=19168 --
[Issue 19168] New: std.random.randomCover and randomSample should warn that struct RNGs are copied (original is not updated)
https://issues.dlang.org/show_bug.cgi?id=19168 Issue ID: 19168 Summary: std.random.randomCover and randomSample should warn that struct RNGs are copied (original is not updated) Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com The behavior is described in https://issues.dlang.org/show_bug.cgi?id=7067. Since the `rng` parameter is `auto ref` this behavior is not obvious merely from the function signature, so at the very least this quirk should be mentioned in the documentation. --
[Issue 19168] std.random.randomCover and randomSample should warn that struct RNGs are copied (original is not updated)
https://issues.dlang.org/show_bug.cgi?id=19168 Nathan S. changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=7067 --
[Issue 18788] static arrays with a length specified at runtime should dynamically allocate on the stack
https://issues.dlang.org/show_bug.cgi?id=18788 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --- Comment #6 from ZombineDev --- LDC has a pass[1] that does escape analysis for class instances and dynamic arrays and stack allocates them when possible. Sadly they do this on the LLVM IR level, so their solution can't be easily upstream-ed to dmd's frontend. Static arrays can't have their length specified at run-time, as it's part of their type. (Just like you can't specify template arguments at run-time. The only thing resembling providing compile-time arguments at run-time is simply instantiating various alternatives at compile-time and selecting one of them at run-time.) What you can do is an array-like struct that wraps alloca. Compile-time safety is out of the question, but it could try to check if it can fit in the remaining stack space minus a several pages. Even so, it would be quite brittle and heavily dependent on platform and run-time specifics (e.g. querying the fiber stack size, when not running on the native thread stack). AFAIK, `scope` is currently inferred only for value types (scalars and static arrays) with -dip1000. Perhaps the inference can be extended to cover dynamic arrays and classes as well. One thing that we must be careful about is that the array memory management [2] built on top of the GC has certain assumptions like looking for block metadata (e.g. array capacity) on its heap. These assumptions may fail if the compiler promotes the array on the stack. But if all of druntime's lifetime code is template-ized, in theory the compiler should be able to see through it and detect that the array .length getter property is trivially scope-friendly, while the setter is not. Don't know how .capacity should be handled. [1]: https://github.com/ldc-developers/ldc/blob/16f37466fe918e0824a3b2db239ba5a7ce5a33cc/gen/passes/GarbageCollect2Stack.cpp [2]: https://github.com/dlang/druntime/blob/bb7e1c0991c0ae43520e67c91d0b7b0d8d315d2e/src/rt/lifetime.d#L1442 --
[Issue 19167] New: Overzealous "Using this as a type is deprecated"
https://issues.dlang.org/show_bug.cgi?id=19167
Issue ID: 19167
Summary: Overzealous "Using this as a type is deprecated"
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: john.loughran.col...@gmail.com
struct A
{
alias a = int;
alias b = this.a;
// Deprecation: Using this as a type is deprecated. Use typeof(this)
instead
}
A a;
alias b = a.a; // OK
This seems inconsistent.
--
