Does dmd not always compile all of the source code?

[user1234]

On Wednesday, 6 December 2017 at 19:19:09 UTC, A Guy With a 
Question wrote:
> On Wednesday, 6 December 2017 at 18:09:45 UTC, Steven 
> Schveighoffer wrote:
>> On 12/6/17 12:17 PM, Steven Schveighoffer wrote:
>>
>>> So why wouldn't the compiler fail? Because it has no idea yet 
>>> what you mean by Nullable. It doesn't even know if Nullable 
>>> will be available or not. You could even import Nullable, but 
>>> Nullable!T may be an error.
>>
>> To give an example of why the compiler waits until 
>> instantiation:
>>
>> class C(T) : T
>> {
>>    void foo() { doesthisexist(); }
>> }
>>
>> class D { void doesthisexist(); }
>>
>> auto x = new C!D; // OK
>> auto y = new C!Object: // fail
>>
>> -Steve
>
> It also doesn't parse or do semantic checks on unit tests 
> unless you add the flag...apparently.
>
> This compiles...
>
> unittest
> {
>     WHY DOESNT THE COMPILER FIND A PROBLEM HERE!?
> }
>
> It seems D's fast compile times are achieved by skipping 
> semantic checking and even parsing when it doesn't feel it's 
> needed. I strongly disagree with this decision. This could 
> leave complex dormant time bombs that break builds unexpectedly 
> and even accidentally.

That's why measuring the level of coverage obtained by the 
unittests is important.
It's not just about the templates, standard if conditions that 
are never tested can also be time bombs, standard functions that 
are never tested can also be time bombs. Even more pernicious in 
a way.