[Issue 532] Wrong name mangling for template alias params of local vars

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Jan 3 03:42:25 PST 2007


http://d.puremagic.com/issues/show_bug.cgi?id=532


clugdbug at yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|0.174                       |0.178




------- Comment #2 from clugdbug at yahoo.com.au  2007-01-03 05:42 -------
(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.


-- 



More information about the Digitalmars-d-bugs mailing list