D compiles fast, right? Right??

[Jonathan Marler]

On Saturday, 31 March 2018 at 21:37:13 UTC, Jonathan M Davis 
wrote:
> On Saturday, March 31, 2018 08:28:31 Jonathan Marler via 
> Digitalmars-d wrote:
>> On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu
>>
>> wrote:
>> > On 3/30/18 12:12 PM, Atila Neves wrote:
>> >> Fast code fast, they said. It'll be fun, they said. Here's 
>> >> a D
>> >>
>> >> file:
>> >>      import std.path;
>> >>
>> >> Yep, that's all there is to it. Let's compile it on my 
>> >> laptop:
>> >>      /tmp % time dmd -c  foo.d
>> >>      dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 
>> >> total
>> >
>> > Could be faster.
>> >
>> >> That... doesn't seem too fast to me. But wait, there's more:
>> >>      /tmp % time dmd -c -unittest foo.d
>> >>      dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu
>> >>
>> >> 0.525 total
>> >
>> > Not fast. We need to make -unittest only affect the built 
>> > module. Even though it breaks certain uses of 
>> > __traits(getUnittests). No two ways about it. Who can work 
>> > on that?
>> >
>> > Andrei
>>
>> If you approve of the -unittest=<pattern> approach then 
>> timotheecour has already offered to implement this.  It's 
>> pattern matching would work the same as -i and would also use 
>> the "implied standard exclusions" that -i uses, namely,
>>
>> -unittest=-std -unittest=-etc -unittest=-core
>>
>> This would mean that by default, just passing "-unittest" 
>> would exclude druntime/phobos just like "-i" by itself also 
>> does.
>
> And every time you used another library, you'd have the same 
> problem and have to add -unittest=- whatever for each and every 
> one of them, or you would have to use -unittest= with 
> everything from your application or library rather than using 
> -unittest. I really don't see how that scales well, and it's 
> way too manual and too easy to screw up. It might be a decent 
> idea for a workaround, but it's not a great solution.
>
> IMHO, this is really something that should be handled by the 
> compiler. It simply shouldn't be compiling in the unittest 
> blocks for modules that you're not compiling directly. And if 
> that's done right, then this whole problem goes away without 
> having to make sure that every project you work on is 
> configured correctly to avoid pulling in the unit tests from 
> everything that it depends on.
>
> And maybe figuring out what to do about __traits(getUnittests) 
> complicates things, but it seems like the fact that we're even 
> having this problem is due to a flaw in the design of D's unit 
> tests and that that should be fixed, not worked around.
>
> - Jonathan M Davis

Let's make this conversation a bit more concrete, I'm not sure we 
are discussing the exact same thing.

The proposed solution is to have -unittest mean "compile 
unittests for all 'compiled modules' according to the pattern 
rules".  The default pattern rule is to include all modules 
except druntime/phobos.

Say you have two "packages" foo and bar that contain modules 
inside their respective directories.  With the proposed 
-unittest=<pattern> this is the semantics you would get.

dmd -unittest       foo/*.d bar/*.d     # compiles unittests for 
foo/*.d and bar/*.d
dmd -unittest=foo   foo/*.d bar/*.d     # compiles unittests for 
foo/*.d
dmd -unittest=bar   foo/*.d bar/*.d     # compiles unittests for 
bar/*.d
dmd -unittest=foo.x foo/*.d bar/*.d     # compiles unittests for 
foo/x.d
dmd -unittest=-bar  foo/*.d bar/*.d     # compiles unittests for 
foo/*.d

Note that the default behavior makes sense, but this mechanism 
also allows you more fine-graned control to limit unittesting to 
certain packages or modules.  This degree of control would be 
quite helpful to me, any of the previously listed use cases 
represent valid scenarios that I would like to be able to do.  Do 
you have another solution that would provide this functionality?  
I don't see any reason not to support these use cases.