D compiles fast, right? Right??

[Jonathan M Davis]

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