[Issue 15019] [ICE] Heisencrash on OS X 32-bit with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #15 from Walter Bright --- I applied the patches and cannot reproduce it :-( --
[Issue 15045] [Reg 2.069-devel] hasElaborateCopyConstructor is true for struct with opDispatch
https://issues.dlang.org/show_bug.cgi?id=15045 --- Comment #2 from Kenji Hara --- IMHO, it would be better to prevent forwarding some built-in special member names prefixed by double-underscore through alias this or opDispatch. As we've already patched in library code like, https://github.com/D-Programming-Language/druntime/pull/1313 forwarding of __xpostblit and __xdtor are hardly useless. >From the dmd internal view, the complete list of "no forward" members would be: __ctor (Id.ctor) __dtor (Id.dtor) __xdtor (Id.__xdtor) __postblit (Id.postblit) __xpostblit (Id.__xpostblit) Following double-underscore member names are invisible with "something.name" syntax, so they don't need to be considered. __fieldDtor (Id.__fieldDtor) __aggrDtor (Id.__aggrDtor) __fieldPostblit (Id.__fieldPostblit) __aggrPostblit (Id.__aggrPostblit) __invariant (Id.classInvariant) __xopEquals (Id.xopEquals) __xopCmp (Id.xopCmp) __xtoHash (Id.xtoHash) If we kill the forwarding for the specific names, we can just modify Type.noMember function behavior. --
[Issue 15045] [Reg 2.069-devel] hasElaborateCopyConstructor is true for struct with opDispatch
https://issues.dlang.org/show_bug.cgi?id=15045 --- Comment #1 from Kenji Hara --- (In reply to Martin Nowak from comment #0) > I'd suggest to fix __traits(hasMember) to not instantiate opDispatch in > which case issue 14605 needs to be refixed. Today, hasMember, getMember, getOverloads, getVirtualMethods, and getVirtualFunctions have consistent result. If we fix the built-in __traits(hasMember), we should also fix other related traits. --
[Issue 14014] struct init required for zero initialized static arrays
https://issues.dlang.org/show_bug.cgi?id=14014 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 14992 *** --
[Issue 14992] static array local variables always require .init
https://issues.dlang.org/show_bug.cgi?id=14992 Kenji Hara changed: What|Removed |Added CC||c...@dawg.eu --- Comment #2 from Kenji Hara --- *** Issue 14014 has been marked as a duplicate of this issue. *** --
[Issue 14756] cannot deduce function with template constraint
https://issues.dlang.org/show_bug.cgi?id=14756 Kenji Hara changed: What|Removed |Added CC||marco.le...@gmx.de --- Comment #2 from Kenji Hara --- *** Issue 15042 has been marked as a duplicate of this issue. *** --
[Issue 15042] [REG2.068] isInstanceOf fails when a template argument is an instance of the tested template
https://issues.dlang.org/show_bug.cgi?id=15042
Kenji Hara changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #3 from Kenji Hara ---
(In reply to Marco Leise from comment #0)
> I have a templated struct that emits an error when you pass in something
> else than "void" or another instance of itself. The following worked with
> 2.067, but fails with 2.068.1:
>
>
>
> import std.traits;
>
> struct RC(Parent)
> {
> static assert (is(Parent == void) || isInstanceOf!(RC, Parent), "This
> used
> to compile in 2.067");
> }
>
> alias Regression = RC!(RC!(void));
>
>
(In reply to Vladimir Panteleev from comment #2)
> Confirmed, introduced in
> https://github.com/D-Programming-Language/dmd/pull/4499
This is an intentional change of PR#4499, which is necessary to kill ambiguity.
And, it's a dup of issue 14756 already marked as invalid.
I've wrote a descriptive comment for that. Please read it if you interest in
the reason and the method to fix your code.
https://issues.dlang.org/show_bug.cgi?id=14756#c1
*** This issue has been marked as a duplicate of issue 14756 ***
--
[Issue 15054] DMD doesn't work with hardening-wrapper
https://issues.dlang.org/show_bug.cgi?id=15054 Marco Leise changed: What|Removed |Added Hardware|x86_64 |All --
[Issue 15054] DMD doesn't work with hardening-wrapper
https://issues.dlang.org/show_bug.cgi?id=15054 Marco Leise changed: What|Removed |Added CC||marco.le...@gmx.de Hardware|All |x86_64 --
[Issue 15056] [REG2.068.1] Unstored RAII struct return yields bogus error: "cannot mix core.std.stdlib.alloca() and exception handling"
https://issues.dlang.org/show_bug.cgi?id=15056 Marco Leise changed: What|Removed |Added Hardware|All |x86_64 OS|All |Linux --
[Issue 15056] [REG2.068.1] Unstored RAII struct return yields bogus error: "cannot mix core.std.stdlib.alloca() and exception handling"
https://issues.dlang.org/show_bug.cgi?id=15056 Marco Leise changed: What|Removed |Added Summary|[REG2.068] Unstored RAII|[REG2.068.1] Unstored RAII |struct return yields bogus |struct return yields bogus |error: "cannot mix |error: "cannot mix |core.std.stdlib.alloca()|core.std.stdlib.alloca() |and exception handling" |and exception handling" --
[Issue 15056] [REG2.068] Unstored RAII struct return yields bogus error: "cannot mix core.std.stdlib.alloca() and exception handling"
https://issues.dlang.org/show_bug.cgi?id=15056 --- Comment #3 from Marco Leise --- I also found those changes in this merge commit for 2.068: https://github.com/D-Programming-Language/dmd/commit/38d31b0364e555ce42a8f47ca656e59b1cf90aad Should I bisect 9rnsr/fix14696_cdmd or is this close enough? --
[Issue 15056] [REG2.068] Unstored RAII struct return yields bogus error: "cannot mix core.std.stdlib.alloca() and exception handling"
https://issues.dlang.org/show_bug.cgi?id=15056 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev --- (In reply to Marco Leise from comment #1) > Digger found this commit in 2.069: > https://github.com/D-Programming-Language/dmd/commit/ > 4f0a458f6072a281892f3d26fdd8aeb30d250c03 > > Since this can not be the commit that broke 2.068 I assume that it broke, > got fixed unintentionally and then broke again. Something seems to be fuzzy > about alloca() handling in the front-end. Digger pointing at a merge commit means it was broken on another branch (which is why Digger stopped on the merge commit). To find the real commit, you'll have to bisect the proper branch (i.e. if you were bisecting master, you'll need to bisect stable). --
[Issue 15056] [REG2.068] Unstored RAII struct return yields bogus error: "cannot mix core.std.stdlib.alloca() and exception handling"
https://issues.dlang.org/show_bug.cgi?id=15056 --- Comment #1 from Marco Leise --- Digger found this commit in 2.069: https://github.com/D-Programming-Language/dmd/commit/4f0a458f6072a281892f3d26fdd8aeb30d250c03 Since this can not be the commit that broke 2.068 I assume that it broke, got fixed unintentionally and then broke again. Something seems to be fuzzy about alloca() handling in the front-end. --
[Issue 15056] New: [REG2.068] Unstored RAII struct return yields bogus error: "cannot mix core.std.stdlib.alloca() and exception handling"
https://issues.dlang.org/show_bug.cgi?id=15056
Issue ID: 15056
Summary: [REG2.068] Unstored RAII struct return yields bogus
error: "cannot mix core.std.stdlib.alloca() and
exception handling"
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: marco.le...@gmx.de
This code snippet illustrates the problem. This would compile on 2.067.1:
1) -
import core.stdc.stdlib;
struct S
{
~this() {}
}
S foo(void* p = alloca(1234))
{
return S();
}
int main()
{
foo();
return 0;
}
With a little change to "main" it compiles again:
void main()
{
S s = foo();
}
Both the removal of a return statement and the storage into an unused variable
are now necessary to work with alloca() in this fashion.
Here is another (complete) test case where RAII and alloca() can't be used in
the same function.
2) -
int main()
{
import core.stdc.stdlib;
struct S { ~this() nothrow {}}
S s;
alloca(1234);
return 1;
}
The use case of 1) is to enable a called function to allocate dynamic memory
from its caller's stack or use malloc() if the memory requirement is large. The
return value is then a RAII struct that - upon destruction - calls free() iff
malloc() was used and does nothing if alloca() was used. This idiom allows for
concise code that executes extremely fast and uses the least possible amount of
stack memory, but must not be used in loops because alloca()'s allocations can
only be released by returning from a function. It is a foundation of my "fast"
library on GitHub.
This broke once before due to the inliner:
https://issues.dlang.org/show_bug.cgi?id=13427
The test case added back then can probably just be extended to cover this new
case.
--
[Issue 15055] isArray!NonArray doesn't short-circuit an expression
https://issues.dlang.org/show_bug.cgi?id=15055
--- Comment #1 from Kenji Hara ---
This is a duplication of enhancement issue 9073.
With static if and static assert, short circuit works for the logical
expressions, like A && B - If A is evaluated to false at compile time, B won't
be evaluated *even if B is an invalid expression*.
On the other hand, an initializer expression on enum variable declaration does
not work as so. With A && B, B is evaluated *always* and will make error if
it's not correct.
In old days, I've opened a PR to fix 9073, but was rejected by Walter.
https://github.com/D-Programming-Language/dmd/pull/2559
To do what you expect, the template should be rewritten to:
template sameUnqualArrays(A, B) {
//enum bool sameUnqualArrays = isArray!A && isArray!B &&
//is(Unqual!(ForeachType!A) == Unqual!(ForeachType!B));
static if (isArray!A && isArray!B &&
is(Unqual!(ForeachType!A) == Unqual!(ForeachType!B)))
{
enum bool sameUnqualArrays = true;
}
else
enum bool sameUnqualArrays = false;
}
--
[Issue 15055] New: isArray!NonArray doesn't short-circuit an expression
https://issues.dlang.org/show_bug.cgi?id=15055
Issue ID: 15055
Summary: isArray!NonArray doesn't short-circuit an expression
Product: D
Version: D2
Hardware: x86_64
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: foldenyi.ta...@gmail.com
I expect the following code run without an error:
template sameUnqualArrays(A, B) {
enum bool sameUnqualArrays = isArray!A && isArray!B &&
is(Unqual!(ForeachType!A) == Unqual!(ForeachType!B));
}
unittest {
static assert(sameUnqualArrays!(ubyte[], immutable(ubyte[])));
static assert(!sameUnqualArrays!(ubyte[], immutable(byte[])));
static assert(!sameUnqualArrays!(ubyte[], ubyte));
}
But the last assert gives an error:
/usr/include/dmd/phobos/std/traits.d(6062,9): Error: invalid foreach aggregate
cast(ubyte)0u
I expect that isArray short circuits the expression before the second half is
evaluated.
I am using DMD64 D Compiler v2.068.0
--
[Issue 15019] [ICE] Heisencrash on OS X 32-bit with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019
Vladimir Panteleev changed:
What|Removed |Added
Assignee|nob...@puremagic.com|bugzi...@digitalmars.com
--- Comment #14 from Vladimir Panteleev ---
(In reply to Vladimir Panteleev from comment #13)
> Anyway, the assert should make the crash deterministic and it should be
> possible to further reduce the test case.
Reduced:
/ test.d
import std.string;
struct Color()
{
static fromHex(char[] s)
{
import std.conv;
s.to!ubyte;
}
}
Color!() RGB;
struct Matrix(T, int R, int C)
{
Vector!(T, C) row_t;
T[C] v;// all elements
/// Covnerts to pretty string.
string toString() const
{
try
return format("%s", v);
catch
assert(false); // should not happen since format is right
}
}
// GLSL is a big inspiration here
// we defines types with more or less the same names
template mat2x2(T) { Matrix!(T, 2, 2) mat2x2; }
template mat3x3(T) { Matrix!(T, 3, 3) mat3x3; }
template mat4x4(T) { Matrix!(T, 4, 4) mat4x4; }
alias mat2x2 mat2;
alias mat3x3 mat3; // shorter names for most common matrices
alias mat4x4 mat4;
string definePostfixAliases(string type)
{
return "alias " ~ type ~ "!byte " ~ type ~ "b;\n"
"alias " ~ type ~ "!ubyte " ~ type ~ "ub;\n"
"alias " ~ type ~ "!short " ~ type ~ "s;\n"
"alias " ~ type ~ "!ushort " ~ type ~ "us;\n"
"alias " ~ type ~ "!int "~ type ~ "i;\n"
"alias " ~ type ~ "!uint " ~ type ~ "ui;\n"
"alias " ~ type ~ "!long " ~ type ~ "l;\n"
"alias " ~ type ~ "!ulong " ~ type ~ "ul;\n"
"alias " ~ type ~ "!float " ~ type ~ "f;\n"
"alias " ~ type ~ "!double " ~ type ~ "d;\n";
}
// define a lot of type names
mixin(definePostfixAliases("mat2"));
mixin(definePostfixAliases("mat3"));
mixin(definePostfixAliases("mat4"));
import std.string;
struct Vector(T, int N)
{
T[N] v;
string toString()
{
try
return format("%s", v);
catch
assert(false);
}
}
/
Trips the assert with: dmd -m32 -c all.d
This is as far as I can go, though. Deferring to machobj.c's author, Walter
Bright.
--
[Issue 15054] New: DMD doesn't work with hardening-wrapper
https://issues.dlang.org/show_bug.cgi?id=15054
Issue ID: 15054
Summary: DMD doesn't work with hardening-wrapper
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pub...@dicebot.lv
Originally reported by Arch Linux user Richard White (rwhite) :
https://bugs.archlinux.org/task/46260
Quotes:
>>>
Description: Both the dmd and ldc (but not the gdc) d compilers in the repos
fail to build anything. It always returns this
/usr/bin/ld: hello.o: relocation R_X86_64_32 against `.rodata' can not be used
when making a shared object; recompile with -fPIC
hello.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
--- errorlevel 1
Steps to reproduce:
Create a *.d file with the trivial program void main(){}
$ dmd filename.d
<<<
>>>
I found the problem. The hardening-wrapper package appends its utils (which
seem to be incompatible with dmd and ldc) to the begging of your path causing
them to be used. Removing the hardening-wrapper and restarting seems to have
fixed the problem.
<<<
Relevant : https://wiki.debian.org/Hardening
--
[Issue 14140] Bad codegen for CTFE union initialisers for immutable structs
https://issues.dlang.org/show_bug.cgi?id=14140 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14140] Bad codegen for CTFE union initialisers for immutable structs
https://issues.dlang.org/show_bug.cgi?id=14140 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c8c56038c1876b24a499e6728f8ae9c2088a80da fix Issue 14140 - Bad codegen for CTFE union initialisers for immutable structs https://github.com/D-Programming-Language/dmd/commit/16969dcd711c82a49acf1f0afdc561fe83b5c859 Merge pull request #5050 from 9rnsr/fix14140 Issue 14140 - Bad codegen for CTFE union initialisers for immutable structs --
[Issue 9057] Regression(Beta): Segfault or "Non-constant expression" error with local import
https://issues.dlang.org/show_bug.cgi?id=9057 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/069f570005c1e571f23cd046b0e89503e2553f70 Add workaround for issue 9057, which is equivalent with the before This is not a new workaround. In previous, the forward reference of struct instance fields had been resolved implicitly in `sd->fields[i].getConstInitializer()`, via `sd->fill()`. --
[Issue 14593] operator overloading can't be used with expression templates
https://issues.dlang.org/show_bug.cgi?id=14593 Artem Borisovskiy changed: What|Removed |Added CC||kolo...@bk.ru --- Comment #5 from Artem Borisovskiy --- (In reply to Martin Nowak from comment #4) > The worst with string arguments is that they can't use variables from the > calling scope. Let's admit it: string mixins are just slightly better preprocessor macros. They sometimes save time, indeed, but there is no D IDE sufficiently smart to expand and semantically analyse them, they're hard to debug, compiler messages don't help much (because we can't see the actual generated code), and code generation for mixins looks messy most of the time, since it usually is just string concatenation. Even if we decide to use format() for prettier string generation, we will immediately have another problem to solve - how to generate code, which itself uses formatting. We can escape %'s, but it looks just as messy as regular expressions in double-quoted strings, and it's too easy to forget to do that. Another problem is parsing a DSL: we can't count on tokenized strings, since there's no way to enforce their usage on the call site, therefore we must even tokenize DSL by hand. AST macros are the only robust _and_ convenient way to generate arbitrary code, and since we don't have them, we should invent other ways, instead of sticking string mixins everywhere and turning our pretty D code into something looking even worse than C preprocessor magic: at least, in C you don't need to concatenate anything most of the time. I'm not sure whether it should be done with operator overloading, but I like your DB query example, it looks intuitive and clean. (In reply to Walter Bright from comment #1) > Using expression templates to implement DSL's makes code really hard to > understand and debug. There are better ways. So do string mixins. What are the other ways? It would be great to have a DSL with maximum assistance from the compiler, i.e. with type checking and minimum boilerplate. How to implement an inline assembler without using string mixins or poking the compiler's guts, for example? We should do better than 40-year old Scheme, otherwise the terrorists (syntactic ones) have won. --
