Bug 532 – Wrong name mangling for template alias params of local vars

In this example, in moo!(A), the value of Mang!(A).mangledname depends on whether it is inside a 'static assert' or not. This seems to be a symptom of a more general problem: I've seen many similar effects, but this is the simplest so far. --------- template Mang(alias F) { class G { } alias void function (G ) H; const char [] mangledname = typeof(H).mangleof; } template moo(alias A) { const char [] a = Mang!(A).mangledname; static assert(Mang!(A).mangledname == a); // FAILS !!! } void main() { int q; char [] b = moo!(q).a; }

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [email protected] schrieb am 2006-11-16: > http://d.puremagic.com/issues/show_bug.cgi?id=532 > In this example, in moo!(A), the value of Mang!(A).mangledname depends on > whether it is inside a 'static assert' or not. This seems to be a symptom of a > more general problem: I've seen many similar effects, but this is the simplest > so far. > > --------- > template Mang(alias F) > { > class G { } > alias void function (G ) H; > const char [] mangledname = typeof(H).mangleof; > } > > template moo(alias A) > { > const char [] a = Mang!(A).mangledname; > static assert(Mang!(A).mangledname == a); // FAILS !!! > } > > void main() > { > int q; > char [] b = moo!(q).a; > } Added to DStress as http://dstress.kuehne.cn/compile/m/mangleof_19_A.d http://dstress.kuehne.cn/compile/m/mangleof_19_B.d http://dstress.kuehne.cn/compile/m/mangleof_19_C.d http://dstress.kuehne.cn/compile/m/mangleof_19_D.d http://dstress.kuehne.cn/compile/m/mangleof_19_E.d http://dstress.kuehne.cn/compile/m/mangleof_19_F.d http://dstress.kuehne.cn/compile/m/mangleof_19_G.d Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFaEUsLK5blCcjpWoRAlGiAKCaYCpRKsMkuhre2cU48TbQL/cH5QCfUGKS 2I+momNVe3BO1MKnC22+u+c= =pQ4D -----END PGP SIGNATURE-----

(In reply to comment #0) > template Mang(alias F) > { > class G { } > alias void function (G ) H; > const char [] mangledname = typeof(H).mangleof; > } > > template moo(alias A) > { > const char [] a = Mang!(A).mangledname; > static assert(Mang!(A).mangledname == a); // FAILS !!! > } > > void main() > { > int q; > char [] b = moo!(q).a; > } Some more information.... Inside the static assert, the type is: void function ( Mang!(bug.main().q).G ); PFC3bug29__T4MangS17_D3bug4mainFZv1qiZ1GZv but outside the static assert, it is: void function ( main.moo(bug.main().q)).Mang!(bug.main().q).G ); PFCmain28__T3mooS17_D3bug4mainFZv1qiZ29__T4MangS17_D3bug4mainFZv1qiZ1GZv The problem is that in this second case, the mangled name of the calling function gets appended to the start of the fully qualified name. I can't see why this would be necessary ('q' is already fully qualified in the alias parameter, so it cannot conflict with anything else). A secondary problem is that in the second case, extern (C),(Windows), (Pascal) symbols such 'main' are not mangled correctly with the new scheme from D0.176: it doesn't have the length information included. main.moo!(...) is Cmain28__T3moo... but it should be C4main28_T3moo... This applies to any extern(C), (Windows), or (Pascal) function, not just "main", but doesn't apply to normal D functions. It is still a problem with D1.0. All other name mangling bugs I've reported since D0.176 seem to be consequences of this one. The mangling used inside the static assert seems natural, and I think it should be used in the other case as well, unless there's a known problem with it.

Changing status to critical because I've seen bad code generation in library code as a result of this bug. There seems to be a fundamental instability in the compiler at this point, almost as though there's an uninitialised variable. This issue is a blocker for my meta.NameOf code.

i change d's version of this bug. and priority to 1 , hope walter could fix this bug sooner.

(In reply to comment #4) > i change d's version of this bug. and priority to 1 , hope walter could fix > this bug sooner. > Please do not change the version number for bug reports. See D.bugs/10071 (http://www.digitalmars.com/webnews/newsgroups.php?search_txt=&group=digitalmars.D.bugs&article_id=10071)

Fixed DMD 1.012.