Difference between "can call" and "can compile"

[Paul Backus]

On Monday, 7 September 2020 at 16:27:46 UTC, Steven Schveighoffer 
wrote:
>
> Thanks! This is the kind of response I'm looking for.
>
> I'm trying to understand what the issue and the solution was in 
> that bug. I'm assuming once the compiler bugs were fixed, then 
> you had to figure out why it wasn't compiling?

It was actually the reverse. SumType's copy constructors were 
failing due to a compiler bug, but the error I was getting was:

src/sumtype.d(1412,4): Error: static assert:  "`handlers[0]` of 
type `template` never matches"

...because the copy constructor uses `match` internally, and 
that's the error `match` gives you when your handler fails to 
speculatively compile. Turning on -verrors=spec allowed me to see 
the error *inside* the handler that was causing speculative 
compilation to fail:

(spec:1) src/sumtype.d-mixin-407(407): Error: union Storage has 
constructors, cannot use { initializers }, use Storage( 
initializers ) instead

...which is what led me to diagnosing and, ultimately, fixing 
issue 20842 [1].

[1] https://issues.dlang.org/show_bug.cgi?id=20842

> I wasn't aware of -verrors=spec, but it sounds like it spitting 
> out ALL speculative errors, not just when a specific call fails 
> to build? While giving a searchable set of data, the situation 
> is only slightly improved.
>
> It is true that if your constraint is the problem, then 
> __traits(canCall) or whatever wouldn't help. But I don't see 
> any constraint changes in that code.

You're right; I was in a hurry when I wrote my post and didn't 
think it through enough. Really, what I want is to see 
speculative errors if and only if they occur during a failed 
attempt at non-speculative template instantiation. In other 
words, when a template fails to instantiate and causes 
compilation to fail, I would like to know why, but if compilation 
succeeds, I don't care about the details. So, 
`-verrors=spec-fatal`, maybe.

It's possible you could even apply this recursively, and only 
show (spec:2) errors if they cause a failed template 
instantiation in (spec:1), etc. I haven't really thought it 
through, though; it's possible that would go too far and end up 
hiding information programmers actually want to see.