Created attachment 1287
Full source code.
Executive summary, full code in the archive attached.
auto instanciateFromResolvedArgs(Location , Template t,
TemplateArgument[] args) {
static Template gladeulfeurah;
gladeulfeurah = t;
string id = args.map!(
({
}, delegate string(identified) {
assert(t is gladeulfeurah, "tagazok");
assert(0);
})
).join;
}
Here, assert(t is gladeulfeurah, "tagazok") fails, when it should succeeed.
Significant part of SDC test suite fail due to this bug (SDC crashes as a
result).
To compile what is provided in the archive :
make DMD=PATH_TO_DMD_MASTER
Run with :
LD_LIBRARY_PATH=PATH_TO_PHOBOS_MASTER ./fail
The whole source code to trigger the error is 3 source file, so it isn't that
big.
Comment #1 by dlang-bugzilla — 2013-11-16T00:22:20Z
OP elaborated on IRC that this is a regression from 2.063.2. The included sample is not fully reduced (DustMite run + cursory Makefile cleanup), but according to OP, separate compilation is required to reproduce the bug.
Comment #2 by deadalnix — 2013-11-16T12:10:06Z
OK, I've been able to spend some time making this report look better.
a.d :
class A {
}
import std.algorithm;
import std.array;
struct TemplateInstancier {
auto instanciateFromResolvedArgs(A a) {
auto bs = [B(a)];
static A gladeulfeurah;
gladeulfeurah = a;
// XXX: have to put array once again to avoid multiple map.
string id = bs.map!(
b => b.apply!(
function string() { assert(0); },
delegate string(i) {
assert(a is gladeulfeurah, "tagazok");
return "";
}
)
).join;
}
}
enum Tag {
Undefined,
A,
}
struct B {
A a;
Tag tag;
this(A a) {
tag = Tag.A;
this.a = a;
}
}
auto apply(alias undefinedHandler, alias handler)(B b) {
final switch(b.tag) with(Tag) {
case Undefined :
return undefinedHandler();
case A :
return handler(b.a);
}
}
fail.d:
import a;
void main() {
auto a = new A();
TemplateInstancier().instanciateFromResolvedArgs(a);
}
Compile via:
dmd -c -offail.o fail.d -m64 -w -debug -gc
dmd -c -ofa.o a.d -m64 -w -debug -gc
gcc -o fail fail.o a.o -m64 -lphobos2 -export-dynamic -ldl
Run via:
./fail
The program assert fail with the message tagazok. The value of the variable a in the closure is incorrect.
Comment #3 by bugzilla — 2013-12-28T21:21:22Z
I can't get this to even link on Linux, the result is:
a.o:(.tbss+0x0): multiple definition of `_D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv13gladeulfeurahC1a1A'
foo.o:(.tbss+0x0): first defined here
a.o: In function `_D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv':
/home/walter/cbx/mars/a.d:7: multiple definition of `_D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv'
foo.o:/home/walter/cbx/mars/a.d:7: first defined here
collect2: ld returned 1 exit status
--- errorlevel 1
The program compiles and runs without error on Windows.
BTW, is it possible for you to simplify the example code? I find it so convoluted as to be completely baffling.
Comment #4 by bugzilla — 2013-12-28T22:42:35Z
This gives the multiple definition error on Linux:
------- a.d -----------
struct A { }
void map(alias dg)(A r) { }
struct TTT {
static auto yyy(A a) {
map!(b => 0)(a);
}
}
------- fail.d ---------
import a;
void main() {
A a;
TTT.yyy(a);
}
-----------------------
REOPENING.
Code supplied in comment 2 still fail as follow :
a.o:(.tbss+0x0): définitions multiples de « _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv13gladeulfeurahC1a1A »
fail.o:(.tbss+0x0): défini pour la première fois ici
a.o: dans la fonction « _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv »:
/home/deadalnix/d/tests/a.d:7: définitions multiples de « _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv »
fail.o:/home/deadalnix/d/tests/a.d:7: défini pour la première fois ici
collect2: error: ld returned 1 exit status
Comment #9 by k.hara.pg — 2014-01-08T22:23:01Z
(In reply to comment #8)
> REOPENING.
>
> Code supplied in comment 2 still fail as follow :
>
> a.o:(.tbss+0x0): définitions multiples de «
> _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv13gladeulfeurahC1a1A
> »
> fail.o:(.tbss+0x0): défini pour la première fois ici
> a.o: dans la fonction «
> _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv »:
> /home/deadalnix/d/tests/a.d:7: définitions multiples de «
> _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv »
> fail.o:/home/deadalnix/d/tests/a.d:7: défini pour la première fois ici
> collect2: error: ld returned 1 exit status
Do you try it with latest git head (b1aa0cb)? If not, recently fixed bug 11863 might also fix this bug.
Comment #10 by deadalnix — 2014-01-09T20:55:22Z
(In reply to comment #9)
> (In reply to comment #8)
> > REOPENING.
> >
> > Code supplied in comment 2 still fail as follow :
> >
> > a.o:(.tbss+0x0): définitions multiples de «
> > _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv13gladeulfeurahC1a1A
> > »
> > fail.o:(.tbss+0x0): défini pour la première fois ici
> > a.o: dans la fonction «
> > _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv »:
> > /home/deadalnix/d/tests/a.d:7: définitions multiples de «
> > _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv »
> > fail.o:/home/deadalnix/d/tests/a.d:7: défini pour la première fois ici
> > collect2: error: ld returned 1 exit status
>
> Do you try it with latest git head (b1aa0cb)? If not, recently fixed bug 11863
> might also fix this bug.
Just tried with the latest git master. Last commit :
commit 41ebb59707444b8e2b0b03a77ec45c6856c7dda8
Merge: 67c7551 59ba51e
Author: Iain Buclaw <[email protected]>
Date: Fri Dec 6 15:22:31 2013 -0800
Merge pull request #2930 from yebblies/ubytecharfixup
[DDMD] Fix a few ubyte/char mismatches that slipped through
Still fail to link with a multiple definition message for symbol _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv13gladeulfeurahC1a1A and _D1a18TemplateInstancier27instanciateFromResolvedArgsMFC1a1AZv
Comment #11 by k.hara.pg — 2014-01-09T21:14:52Z
(In reply to comment #10)
> Just tried with the latest git master. Last commit :
>
> commit 41ebb59707444b8e2b0b03a77ec45c6856c7dda8
> Merge: 67c7551 59ba51e
> Author: Iain Buclaw <[email protected]>
> Date: Fri Dec 6 15:22:31 2013 -0800
>
> Merge pull request #2930 from yebblies/ubytecharfixup
>
> [DDMD] Fix a few ubyte/char mismatches that slipped through
"Fri Dec 6" !? It's committed at a month ago.
I meant that the commit at three days ago.
commit 6090f4599b4da0a642796c1d2655a26f0ce99b17
Merge: 044717c 4c846a2
Author: Don Clugston <[email protected]>
Date: Tue Jan 7 00:09:49 2014 -0800
Merge pull request #3069 from 9rnsr/fix11863
[REG2.064] Issue 11863 - std.conv.to!string(int/uint, radix) returns incorrect string
Comment #12 by deadalnix — 2014-01-10T07:56:17Z
(In reply to comment #11)
> (In reply to comment #10)
> > Just tried with the latest git master. Last commit :
> >
> > commit 41ebb59707444b8e2b0b03a77ec45c6856c7dda8
> > Merge: 67c7551 59ba51e
> > Author: Iain Buclaw <[email protected]>
> > Date: Fri Dec 6 15:22:31 2013 -0800
> >
> > Merge pull request #2930 from yebblies/ubytecharfixup
> >
> > [DDMD] Fix a few ubyte/char mismatches that slipped through
>
> "Fri Dec 6" !? It's committed at a month ago.
>
> I meant that the commit at three days ago.
>
> commit 6090f4599b4da0a642796c1d2655a26f0ce99b17
> Merge: 044717c 4c846a2
> Author: Don Clugston <[email protected]>
> Date: Tue Jan 7 00:09:49 2014 -0800
>
> Merge pull request #3069 from 9rnsr/fix11863
>
> [REG2.064] Issue 11863 - std.conv.to!string(int/uint, radix) returns
> incorrect string
OK for some reason my git repo was broken and I wasn't pulling. This is fixed. Thanks !
Comment #13 by deadalnix — 2014-01-25T17:57:43Z
The bug is back in master. Reopening.
Comment #14 by bugzilla — 2014-01-26T12:58:55Z
(In reply to comment #13)
> The bug is back in master. Reopening.
1. Which test case?
2. Failing to link, or failing to run?
Comment #15 by deadalnix — 2014-01-26T13:21:40Z
(In reply to comment #14)
> (In reply to comment #13)
> > The bug is back in master. Reopening.
>
> 1. Which test case?
> 2. Failing to link, or failing to run?
Code provided in comment 2 compile and link, but the values captured in the closure are bogus.
Comment #16 by bugzilla — 2014-01-26T14:19:09Z
(In reply to comment #15)
> Code provided in comment 2 compile and link, but the values captured in the
> closure are bogus.
What happens if you try linking it normally, i.e.:
dmd -m64 fail.o a.o
?
Comment #17 by bugzilla — 2014-01-26T16:25:09Z
(In reply to comment #16)
> (In reply to comment #15)
> > Code provided in comment 2 compile and link, but the values captured in the
> > closure are bogus.
>
> What happens if you try linking it normally, i.e.:
>
> dmd -m64 fail.o a.o
>
> ?
Never mind, I can repro the failure on Windows with master.
Comment #18 by bugzilla — 2014-01-26T16:41:25Z
Grumble, this is great, 61 source files changed since it worked, and probably 10,000 lines changed.
Comment #19 by dlang-bugzilla — 2014-01-26T16:43:04Z
This sounds like a job for D-dot-git! I can find the exact commit that introduced the regression, I just need: 1) the last commit where it worked, and 2) files/instructions on how to reproduce the problem on Windows.
Comment #20 by bugzilla — 2014-01-26T16:47:39Z
Somewhere between:
commit 11f05b5dad2f5ef22a73dd851db1ec108508e022
Merge: cb5ace9 91a5c8a
Author: Hara Kenji <[email protected]>
Date: Thu Jan 16 05:54:22 2014 -0800
and:
commit edc0125846974e34bf153c21f2d5cb40141ff3e1
Merge: 01ca07b 57e1395
Author: Walter Bright <[email protected]>
Date: Sun Jan 26 12:17:17 2014 -0800
the bug reappeared. Anyone feel like doing a git bisect?
Comment #21 by bugzilla — 2014-01-26T16:48:30Z
To repro on Windows:
dmd -c fail.d -w -debug -gc
dmd -c a.d -w -debug -gc
dmd fail.obj a.obj
fail
Comment #22 by dlang-bugzilla — 2014-01-26T16:49:32Z
I'm on it!
Comment #23 by bugzilla — 2014-01-26T16:50:41Z
(In reply to comment #22)
> I'm on it!
Thank you! You da man!
Comment #24 by dlang-bugzilla — 2014-01-26T17:08:41Z
For me, this bug is reproduced even on 11f05b5dad2f5ef22a73dd851db1ec108508e022
. However, this can be because of the Phobos dependency in comment#2. I am going to try to reproduce it on Linux and remove the Phobos dependency.
Comment #25 by bugzilla — 2014-01-26T17:25:01Z
(In reply to comment #24)
> For me, this bug is reproduced even on 11f05b5dad2f5ef22a73dd851db1ec108508e022
> . However, this can be because of the Phobos dependency in comment#2. I am
> going to try to reproduce it on Linux and remove the Phobos dependency.
Hmm, I was using the Jan 16 phobos for both runs.
Comment #26 by dlang-bugzilla — 2014-01-26T17:50:32Z
Comment #27 by dlang-bugzilla — 2014-01-26T17:57:06Z
5321d36d12dfe0b3c18cdb9755ea6342ebe664b3 is the first bad commit
commit 5321d36d12dfe0b3c18cdb9755ea6342ebe664b3
Author: k-hara <[email protected]>
Date: Sat Jan 18 14:42:41 2014 +0900
fix Issue 11931 - Linkers "Symbol Undefined" again with dmd HEAD when -g specified
Also add test case for issue 7595.
:040000 040000 831cbb65162bb4de49c865cbb4c497165e1df18b bf75df6e2964a3a1666ead1ca19f9c723afb4cf8 M src
:040000 040000 d37c2c62637a6d3b1c2b60455b46a0cd5e7b4385 2dfd0ee0660e40585c6960235f57d1103c952a7f M test
bisect run success