D compiles fast, right? Right??

[Steven Schveighoffer]

On 4/2/18 3:55 PM, H. S. Teoh wrote:
> 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.

Yes, I think this approach (at least, parsing unittests but deferring 
semantic until invoked) is the correct way to avoid breakage. It may be 
easy enough to do this without "treating it as a template", but I'm not 
sure.

-Steve