Unhelpful error messages

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jul 8 13:44:57 PDT 2013


On Mon, Jul 08, 2013 at 09:47:46PM +0200, Peter Alexander wrote:
> On Monday, 8 July 2013 at 18:10:45 UTC, H. S. Teoh wrote:
> >On Sun, Jul 07, 2013 at 02:06:46PM +0200, Peter Alexander wrote:
> >>It's a tough situation and I think the only way this could even
> >>reasonably be resolved is through some sophisticated IDE
> >>integration. There is no way to display this kind of error report in
> >>a blob of command line text.
> >
> >I don't see how an IDE could do better than the compiler.
> >Combinatorial explosion is a nasty problem, and if an IDE could solve
> >it, so could the compiler. Sure, the IDE could give you a nice
> >scrollable GUI widget to look through all the various reasons of the
> >instantiation failure, but fundamentally speaking, that's not much
> >different from running grep through 50 pages of compiler output. You
> >still haven't solved the root problem, which is to narrow down the
> >exponential set of possible problem causes to a manageable,
> >human-comprehensible number.
> 
> I thinking of more of an interactive diagnostic: you choose which
> overload you intended to instantiate and then get a list of reasons
> why that failed to compile. Repeat recursively for any sub-calls.

The problem is, this presumes knowledge of Phobos internals, which most
D users probably would have no clue about. How is one supposed to know
which of the 25 overloads should be used in this particular case anyway?
For all one knows, it may be a Phobos bug or something.

Whereas a message like "cannot instantiate S in std.blah.internal.func"
where S is the user-defined struct, would be a good indication as to
what might be wrong without needing to understand how Phobos works.


> Maybe the compiler could just spew out every possible error for every
> instantiation, and expect the user to grep, but that's not going to be
> a pleasant experience.

The original problem, though, was that the error happened inside a
signature constraint, so it was gagged. The actual error that caused the
failure was *suppressed*. The stuff that happened afterwards -- the
reams of failed overload candidates, etc., are just collateral damage.
The real issue here is that the primary cause of the problem has been
gagged but the collateral damage fills the screen.

That's why I said, had toImpl been written in a way that voluntarily
took up all structs, instead of silently declining one that failed to
compile (and gagging the offending error), then the actual cause of the
problem would've been at least there to be found, even if it's buried in
15 pages of errors. Right now, it's not even *visible*; you have to
first sort through the collateral damage and *guess* where the problem
might be, before you could even pick up any trail of the evidence. And
then you still can't get an actual error message out of it; you have to
basically copy-n-paste the toImpl overload, sans signature constraint,
into your code before the compiler will even give you an error message
that gives any indication as to what the problem is.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL


More information about the Digitalmars-d mailing list