www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unhelpful error messages

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
I'm posting this here 'cos I've no idea how to improve it, but it's
definitely a problem:

First, let's define a struct that overloads opCast:

	struct S {
		T opCast(T)()
			if (is(T == struct))
		{
			T t;
			return t;
		}
	}

The code above is just a stub implementation; the idea is that S would
store some kind of key/value pairing, and opCast would automatically
assign key/value pairs to struct fields (hence the signature constraint
is(T==struct)). The reason opCast is used is to integrate nicely with
std.conv:

	unittest {
		S s;
		... // add some key/value pairs to s

		struct T {
			int x, int y;
		}

		auto t = to!T(s);
	}

On DMD, this works OK. But if we add a method to T:

	unittest {
		S s;
		... // add some key/value pairs to s

		struct T {
			int x, int y;
			bool f() { return true; }
		}

		auto t = to!T(s);
	}

The existence of T.f() causes T to acquire an implicit context pointer,
which is a separate issue, but what I'm trying to get at here is, the
resulting error message is completely unhelpful: it just shows about 20
or so lines of errors saying that std.conv.to cannot be instantiated,
and that it doesn't match any of a large number of toImpl overloads.
But there is no indication whatsoever why that might be so -- after all,
opCast *is* defined! -- the signature constraint in toImpl that looks
for opCast is written like this:

    if (is(typeof(S.init.opCast!T()) : T) && ...

The problem is, if S.init.opCast!T() fails to compile for *any* reason,
the signature constraint declines, but the user is left with no clue as
to why!

The cause of the problem only becomes clear if you replace to!T(s) with
s.opCast!T(), then the compiler will tell you exactly what's wrong with
opCast (in this case, that T cannot be instantiated outside of its
definition scope).

In fact, you can insert a random error into opCast and you wouldn't know
any better (as long as it's syntactically correct), since if you never
call it directly, only via std.conv.to, then you'll only ever see the
opaque wall of template instantiation failures, not the *real* reason
for the failure.

I don't know how to improve this situation. One thought is to rewrite
toImpl's signature constraint to only check for the *existence* of
opCast, so that any subsequent compile errors will become visible (even
if ugly). But that doesn't work for cases where something else may match
the signature constraints of another toImpl overload.

But the current state of things is very unhelpful -- you keep getting an
error that to!T() can't be instantiated, but all you see is that all the
toImpl overloads rejected T. Then if you comment out the "T t;" line in
opCast and replace the return with "return T.init", then things
mysteriously begin to work again. In fact, adding random changes into
opCast will either compile if you're lucky, or complain that to!T()
can't be instantiated. No message about any syntax error or other error
in opCast is ever given. You could be missing a case in a switch
statement, and all you'd learn is that to!T() can't be instantiated --
opCast isn't even mentioned anywhere, so you wouldn't even know to look
there in the first place!

Clearly, something needs to be improved, but it's unclear *what*, or
how.


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see
through walls. It was called the "window".
Jul 06 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
http://d.puremagic.com/issues/
Jul 06 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 7 July 2013 at 06:58:29 UTC, Maxim Fomin wrote:
 http://d.puremagic.com/issues/
Ironically, this isn't helpful. H. S. Teoh is opening up a discussion, not reporting a bug. The problem here is more general than this specific case. Any template constraint on any function could fail to pass, and the best error you'll get is that it couldn't match any function. Even if the error messages were improved to tell you what part of the constraint failed, you still have no idea *why* it failed (e.g. *why* is my range not a forward range?) Overloads just make matters exponentially worse. Not only can the compiler fail to provide a good error for a single function, but needs to provide a good error for every possible candidate function. If a constraint checks if another overloaded function is callable then you end up with a combinatorial explosion of reasons why your function didn't compile. 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.
Jul 07 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jul 07, 2013 at 02:06:46PM +0200, Peter Alexander wrote:
[...]
 The problem here is more general than this specific case. Any
 template constraint on any function could fail to pass, and the best
 error you'll get is that it couldn't match any function. Even if the
 error messages were improved to tell you what part of the constraint
 failed, you still have no idea *why* it failed (e.g. *why* is my
 range not a forward range?)
 
 Overloads just make matters exponentially worse. Not only can the
 compiler fail to provide a good error for a single function, but
 needs to provide a good error for every possible candidate function.
 If a constraint checks if another overloaded function is callable
 then you end up with a combinatorial explosion of reasons why your
 function didn't compile.
 
 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 think the crux of the problem is that there's no reasonable way to tell the difference between toImpl!(float)'s signature constraint declining a particular instantiation because you're trying to convert a struct, vs. toImpl!(struct)'s signature constraint declining it because the struct causes compile errors. If toImpl!(struct) accepted *all* struct instantiations, then when a compile error occurs it would be much easier to track it down to a problem with the struct. You'd know that toImpl actually supports converting a struct, but due to the struct's non-conformance to some requirements, this particular attempt failed. You'd be able to pinpoint the problem to the struct immediately, rather than wondering whether the problem was that toImpl doesn't support struct conversions. But by rejecting all non-compiling types (including structs) outright, it's basically pushing the problem up to the level of which of the 25 overloads of toImpl should be chosen for this particular instantiation -- 24 overloads of which have nothing whatsoever to do with structs. That's where the combinatorial explosion comes from. T -- Computers aren't intelligent; they only think they are.
Jul 08 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
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. 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.
Jul 08 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jul 08 2013
parent reply "Don" <turnyourkidsintocash nospam.com> writes:
On Monday, 8 July 2013 at 20:46:35 UTC, H. S. Teoh wrote:
 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 compiler could join all the constraints and then simplify it to create the error message. (eg by creating a Binary Decision Diagram (BDD)) eg given constraints: if ( A && B && C ) if ( (A && D) || ( A && E && F) ) if ( E && G ) Suppose A is true but the conditions fail. The compiler could then write that no templates match because ( B || D || E ) is false.
Jul 10 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 10, 2013 at 03:05:25PM +0200, Don wrote:
 On Monday, 8 July 2013 at 20:46:35 UTC, H. S. Teoh wrote:
On Mon, Jul 08, 2013 at 09:47:46PM +0200, Peter Alexander wrote:
[...]
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 compiler could join all the constraints and then simplify it to create the error message. (eg by creating a Binary Decision Diagram (BDD)) eg given constraints: if ( A && B && C ) if ( (A && D) || ( A && E && F) ) if ( E && G ) Suppose A is true but the conditions fail. The compiler could then write that no templates match because ( B || D || E ) is false.
+1. Now that's cool, and is something actually implementable. Can we have this pretty please? :-) T -- The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava
Jul 10 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 10, 2013 at 03:05:25PM +0200, Don wrote:
 On Monday, 8 July 2013 at 20:46:35 UTC, H. S. Teoh wrote:
On Mon, Jul 08, 2013 at 09:47:46PM +0200, Peter Alexander wrote:
[...]
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 compiler could join all the constraints and then simplify it to create the error message. (eg by creating a Binary Decision Diagram (BDD)) eg given constraints: if ( A && B && C ) if ( (A && D) || ( A && E && F) ) if ( E && G ) Suppose A is true but the conditions fail. The compiler could then write that no templates match because ( B || D || E ) is false.
[...] Hmm, looking at BDD's again, it appears that the simplification process may not be quite so simple. Depending on the ordering of constraints, you may end up with a BDD of exponential length. The bad thing is that finding the best ordering is NP-hard. There are heuristic algorithms that work well for "normal" cases, though, so hopefully this won't be *too* nasty to implement. T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Jul 12 2013