July 04Separate compilation identifier mess and the bug trail that ensued
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?
Copyright © 1999-2018 by the D Language Foundation