[Dlang-internal] Separate compilation identifier mess and the bug trail that ensued

[Atila Neves]

Once upon a time, one could not use __traits(getUnitTests) and 
separate compilation, and it begat 
https://issues.dlang.org/show_bug.cgi?id=16995. The problem was 
that there was a counter being used to name unittests, and it 
varied between running the compiler on all files at once (or in 
groups) versus compiling files separately.

Due to a suggestion in the PR, I emulated what was done for 
naming lambdas and delayed naming the unittest until semantic 
analysis. This begat 
https://issues.dlang.org/show_bug.cgi?id=18097 since now one 
could not longer take the address of a unittest function. Well, 
one could but it wouldn't link because it'd be the wrong name by 
the time semantic was done with it.

I went back and undid the semantic setting of the identifier and 
used the file name in the unittest name instead. That begat 
https://issues.dlang.org/show_bug.cgi?id=18111. The name of the 
file isn't the absolute path, and so depending on how the 
compiler is invoked, one still gets linker errors.

I realised the stupidity of my ways - D already mangles according 
to module, and those names are always the same no matter how one 
compiles. I went back to a simpler time, but without the counter, 
relying on line/column numbers instead. That begat 
https://issues.dlang.org/show_bug.cgi?id=18880. Using `static 
foreach` or mixing in unittests with strings meant that the 
different unittests shared line and column numbers. Oops.

In trying to fix https://issues.dlang.org/show_bug.cgi?id=18868 
Johan got a comment about the bug mentioned above and added a fix 
for that as well. Which breaks __traits(getUnitTests) and 
separate compilation, since it uses a counter to disambiguate 
between identical identifiers. But counters can't and won't work, 
because identifiers don't have fully qualified names until 
semantic, and when they're created they might have the exact same 
identifier as a symbol in a different module. Those don't need to 
be disambiguated of course, but there's no way for the compiler 
to know ahead of time. Chaos ensues.

I've been racking my brain thinking about to solve this. I can't 
use file names or rely on the module name (after the symbol has a 
module attached to it), since that has caused bugs in the past 
and would again. The file name doesn't work unless I somehow 
always get the absolute path. Using the module information means 
that at different points of compilation symbols change names.

Does anyone have a good idea of a way out?