[Bug c++/51149] New: Smarter error output in a few template deduction/substitution failure cases

[Bug c++/51149] New: Smarter error output in a few template deduction/substitution failure cases

[darlingmoff at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51149

             Bug #: 51149
           Summary: Smarter error output in a few template
                    deduction/substitution failure cases
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: darlingmoff@gmail.com


I have a suggestion of making error output in two cases more helpful.  I've got
to admit that I don't know if there's a good way to implement this.

It's really nice that g++ makes suggestions, for when you're a little bit off
the mark.

But, there's two situations I tend to do all the time that cause several pages
of irrelevant suggestions/template failures fly by.  If you do several of these
at once, it takes a while to find the offending line numbers.  I often scroll
to top of errors, fix that line, try recompiling.  I'm not able to efficiently
pick out the line numbers all at once, since there's so much between the lines
I need to read.

I like the feature of g++ saying "maybe you meant ->" if you use "." on a
pointer.  If there would be a way to implement something like that on these
cases, it would be nice.


Case - When working a lot with streams, forgetting you're momentarily working
with a string
[example]string theString = anotherString << "text";  // note it should be
"+"[/example]

In this case, g++ gives many, many lines showing template argument
deduction/substitution failed, where if a single line would do that states
"maybe you meant + instead of <<".


Case - When meaning to call a lambda function, forgetting parenthesis
[example]auto lambda = [] { return "text"; };
if("text" == lambda) cout << "It's text" << endl;  // note it should be
"lambda()"[/example]

In this case, g++ gives many, many lines showing template argument
deduction/substitution failed, where if a single line would do that states
"maybe you forgot ()".


I do realize that the errors it gives are helpful in situations where someone
hasn't made one of these typos, so I realize that giving these shorter error
messages might be helpful to me, but less helpful to others.  That's why I said
I'm not sure if there's a good way to implement this, but I hope there is.

[Bug c++/51149] Smarter error output in a few template deduction/substitution failure cases

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51149

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-11-16 08:13:54 UTC ---
Could you provide self-contained testcases?

What do you mean by "forgetting you are working with strings"? Would it help if
the compiler reminded it to you like in:

pr51149.cc:8:36: error: invalid operands to binary expression ('string' (aka
'basic_string<char>') and 'const char [5]')
  string theString = anotherString << "text";
                     ~~~~~~~~~~~~~ ^  ~~~~~~

I think it is very hard to guess in general that you meant something if you
wrote something else. Why suggest "+" and not something else? Also, it may make
sense with "std::string", but what about every other possible or standard type?
What is the correct guess there?

[Bug c++/51149] Smarter error output in a few template deduction/substitution failure cases

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51149

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-16 11:23:19 UTC ---
(In reply to comment #0)
> But, there's two situations I tend to do all the time that cause several pages
> of irrelevant suggestions/template failures fly by.  If you do several of these
> at once, it takes a while to find the offending line numbers.  I often scroll
> to top of errors, fix that line, try recompiling.  I'm not able to efficiently
> pick out the line numbers all at once, since there's so much between the lines
> I need to read.

Use -fmax-errors=n to limit the output to n errors.

Or -Wfatal-errors to stop at the first error.


> Case - When working a lot with streams, forgetting you're momentarily working
> with a string
> [example]string theString = anotherString << "text";  // note it should be
> "+"[/example]
> 
> In this case, g++ gives many, many lines showing template argument

No it doesn't, it prints one line saying no match for operator<<, then shows a
single candidate function and tells you why it failed.

> deduction/substitution failed, where if a single line would do that states
> "maybe you meant + instead of <<".

But maybe you meant '=' instead.  I find that automated advice on how to fix a
problem is fine when it's correct, but if it gives the wrong advice it can
waste even more time leading you in the wrong direction.

I don't think this mistake is common enough to warrant special treatment.


> Case - When meaning to call a lambda function, forgetting parenthesis
> [example]auto lambda = [] { return "text"; };
> if("text" == lambda) cout << "It's text" << endl;  // note it should be
> "lambda()"[/example]
> 
> In this case, g++ gives many, many lines showing template argument
> deduction/substitution failed, where if a single line would do that states
> "maybe you forgot ()".

This doesn't only apply to lambdas but any callable object:

int f() { return 1;}

struct F { int operator()() { return 1; } } ff;

bool b1 = ( f == 1 );
bool b2 = ( ff == 1 );

It might be possible to check whether 'f()' would have made the expression
valid, but that would have to be done for all types in all invalid expressions
(including e.g. your 'anotherString << "text"' example, which would have to
check if 'anotherString() << "text"' makes a valid expression)