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)