fullyQualifiedName on enum template members doesn't work

[dlangBugzillaToGithub]

thelastmammoth reported this on 2013-05-28T01:49:08Z

Transfered from https://issues.dlang.org/show_bug.cgi?id=10190

CC List

• ag0aep6g
• andrej.mitrovich (@AndrejMitrovic)
• public (@mihails-strasuns)
• thelastmammoth

Description

import std.stdio;
import std.traits;

template A(T){
	struct A{
		T x;
		void foo(int z){}
	}
}
void main(){
	enum b=A!int.init;
	auto c=A!int.init;
	writeln(fullyQualifiedName!(A!int.init));
	writeln(fullyQualifiedName!(b));
	writeln(fullyQualifiedName!(c));
}


prints:
T
T
tests.main.main.c

is that normal to print T ?

[dlangBugzillaToGithub]

public (@mihails-strasuns) commented on 2013-05-28T02:20:00Z

Looks like this was caused by my pull https://github.com/D-Programming-Language/phobos/pull/1182

"(__traits(identifier, T)" is evaluated to "T" for some reasons with this snippet. On it.

[dlangBugzillaToGithub]

public (@mihails-strasuns) commented on 2013-05-28T02:38:03Z

Ok, there are two issues here.

First one is that identifier trait fails badly with temporaries, minimal example:
----------------------------------------
template oops(alias T)
{
    enum oops = __traits(identifier, T); 
}

struct A {}

pragma(msg, oops!(A.init));

void main()
{
}
----------------------------------------

Second looks like some sort of data reusage compiler bug - once identifier trait was called on a temporary, using it on normal symbols breaks too (yields same rersult).

[dlangBugzillaToGithub]

public (@mihails-strasuns) commented on 2013-06-14T01:24:26Z

I feel like I need an advice from someone from core DMD team on this - should I try to detect and workaround incoming temporaries in std.traits code or this is __traits(identifier) bug and need to be fixed in DMD itself?

[dlangBugzillaToGithub]

andrej.mitrovich (@AndrejMitrovic) commented on 2014-04-24T12:14:30Z

Seems similar to https://issues.dlang.org/show_bug.cgi?id=12287

[dlangBugzillaToGithub]

ag0aep6g commented on 2015-04-25T20:22:03Z

(In reply to Dicebot from comment #2)
> Second looks like some sort of data reusage compiler bug - once identifier
> trait was called on a temporary, using it on normal symbols breaks too
> (yields same rersult).

Filed that as issue 14501.