https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120421
--- Comment #5 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Andrew Pinski from comment #4)
> But printing out the preprocessed line is equally as wrong in many cases.
> Especially when it comes to `#line` markers. That is it is there is no
> correct answer and clang can be shown to be broken too in some cases too.
It avoids that problem by not using the line number for figuring out which line
to print in diagnostics. If I insert '#line 10000 "b.cc"' at the start of the
test (in fact no "b.cc" exists), the output becomes:
$ clang++ -c a.cc
b.cc:10007:6: error: use of undeclared identifier 'xxxxx'
10007 | fcn(xxxxx); // comment
| ^
1 error generated.
$ clang++ -c a.cc -save-temps
b.cc:10007:14: error: use of undeclared identifier 'xxxxx'
10007 | longNamefcn(xxxxx);
| ^
1 error generated.
Although it reports "b.cc:10007", it does not attempt to use that to print line
10007 from the preprocessor output or anything like that, it manages to just
print the actual line that the error appeared on, and because it manages to do
that, it also manages to put the caret in the appropriate position to indicate
where the identifier is that is causing the error.
I can believe that there are corner cases that Clang gets wrong, but the
general approach is sound, there is no fundamental reason why it cannot work in
all cases, and of course there is no reason for a reimplementation of that
approach in GCC to copy any bugs.
