D compiles fast, right? Right??

[H. S. Teoh]

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.