3

Whenever gcc can't find a matching overload for a function with multiple overloads, it gives lines and lines of errors, explaining which overload was tried and why it was not used.

While often it is useful, it is also often not, as the problem as a simple typo at the call site. And in this particular case, it is not even helpful, because it will take considerable time to even find out which line is ultimately responsible for this issue.

Is there any command line switch to GCC to shorten the output and only include the actual triggering line? For example:

#include <string>
#include <iostream>

struct Z{};

void foo() {

    std::string s;
    Z z;

    std::cout << z; // typo - meant s 
}

See error output: https://godbolt.org/g/wz5vL2

Small addition: third party solutions (STLFilt, gccfilter, etc) do not fit the bill, because a) my work environment is not welcoming towards installing 3rd party apps and b) they tend to become unmaintained and stop working with the next compiler upgrade

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • [Related](https://stackoverflow.com/questions/656420/is-there-any-way-to-get-readable-gcc-error-and-warning-output-at-the-command-lin) [related](https://stackoverflow.com/questions/24928244/how-to-hide-defaulted-template-parameters-in-gcc-error-messages). – user202729 Apr 04 '18 at 14:13
  • Just grep your `filename.cpp:`... (of course this is not a "command line switch to GCC") – user202729 Apr 04 '18 at 14:13
  • Better grep gcc's output: `g++ filename.cpp -fdiagnostics-color=always | head -30`. – bipll Apr 04 '18 at 14:21
  • The first error message that appears for this error is `:11:15: error: no match for 'operator<<'`, which seems pretty straightforward and gives the location in your code. There are cases where it's hard to find where the error is from the message but this isn't one of them. – interjay Apr 04 '18 at 14:25
  • @interjay, yes, I just couldn't quickly construct MCVE with those. There are cases when the actual error line could only be seen in like `required from here` message. – SergeyA Apr 04 '18 at 14:33
  • 1
    Does https://stackoverflow.com/q/13025773/27302 help? I’m reluctant to close as a duplicate in case `gccfilter` hasn’t been maintained or you need a flag for some reason, but it might work. Failing that the only other option I found was https://stackoverflow.com/q/11313600/27302, and I hope there’s a better solution by now. – Daniel H Apr 04 '18 at 14:39
  • @DanielH no, gccfilter doesn't help, because I work in environment where installing 3rd-party extra apps is problematic. – SergeyA Apr 04 '18 at 14:42
  • "it will take considerable time to even find out which line is ultimately responsible for this issue" - not really. With `-fdiagnostics-color=always` corresponding line is colored in red and can be found relatively easy. – ks1322 Apr 04 '18 at 14:48
  • The "required from here" message appears when you're using templates. Like this: https://godbolt.org/g/d9gqtX. The problem is that there's no way for the compiler to know if the typo was in the template or the code which uses it, so it shows both. If you had a solution that hides one of them, it might hide the actual culprit. – interjay Apr 04 '18 at 14:52
  • @interjay Certainly, this is why it could be a switch and people could use it... On any rate, no means no. – SergeyA Apr 04 '18 at 18:06
  • Here's a common trick : the existence of tools often points to the need for those tools. If tool Y takes the output of tool X to do some operation Foo, then presumably Y was created because X can't do Foo. So substitute X=gcc, Y=gccfilter, and Foo=this question. That givs us the answer, "no, gcc can't do what gccfilter does, else why would gccfilter exist?" – MSalters Apr 05 '18 at 10:25
  • @MSalters not really, especially in open source domain. First of, gcc filter is old. Something could pop along. Second off, people who were doing gccfilter might have had their reasons. – SergeyA Apr 05 '18 at 13:18

1 Answers1

9

One way is to use -Wfatal-errors. It changes the error message from

<source>: In function 'void foo()':

<source>:11:15: error: no match for 'operator<<' (operand types are 'std::ostream {aka std::basic_ostream<char>}' and 'Z')

     std::cout << z; // typo - meant s

     ~~~~~~~~~~^~~~

In file included from /opt/compiler-explorer/gcc-7.3.0/include/c++/7.3.0/iostream:39:0,

                 from <source>:2:

/opt/compiler-explorer/gcc-7.3.0/include/c++/7.3.0/ostream:108:7: note: candidate: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type& (*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char; _Traits = std::char_traits<char>; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream<char>]

       operator<<(__ostream_type& (*__pf)(__ostream_type&))

many more lines of errors

to

    <source>: In function 'void foo()':

<source>:11:15: error: no match for 'operator<<' (operand types are 'std::ostream {aka std::basic_ostream<char>}' and 'Z')

     std::cout << z; // typo - meant s

     ~~~~~~~~~~^~~~

compilation terminated due to -Wfatal-errors.

Compiler returned: 1

The only downside is you will only get the first error. If your compile times are long then this isn't the greatest as you wouldn't be able to fix any other errors until you fix that first one and recompile.

NathanOliver
  • 171,901
  • 28
  • 288
  • 402