Unhelpful error messages

[Don]

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.