On Mon, Apr 02, 2018 at 03:28:02PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] > We really need to change the unittest import strategy. [...]
I think this has been established beyond reasonable doubt for the last little while. What about we start hashing out a solution? AFAIK, the current proposal is to make it so that `-unittest` only takes effect on modules that are being compiled (i.e., specified on the command-line). Imported modules will *not* have unittests compiled, unless they have also been specified on the command-line. The only thing blocking this proposal that I'm aware of, is that it will break __traits(getUnitTests). But I'm not sure if that's actually a serious problem at all. What if we make it so that a unittest block in an imported module that isn't specified on the command-line is basically treated as a template? I.e., parse the AST, but don't do anything with it. Don't bother running semantic, don't bother resolving identifiers (in particular, import statements inside the unittest), etc.. Just leave it in the AST as essentially translated syntax. Then if __traits(getUnitTests) is ever invoked, run semantic on the unittests in the targeted module. I'm not 100% certain, but I have a suspicion that this will mitigate the breakage to __traits(getUnitTests) without compromising on the "don't compile unittests outside the current list of modules to compile" fix. T -- Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.
