Re: [PATCH] RFC: elide repeated source locations (PR other/84889)

[Martin Sebor <msebor@gmail.com>]

On 11/11/2018 07:43 PM, David Malcolm wrote:
> We often emit more than one diagnostic at the same source location.
> For example, the C++ frontend can emit many diagnostics at
> the same source location when suggesting overload candidates.
>
> For example:
>
> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C: In function 'int test_3(s, t)':
> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C:38:18: error: no match for 'operator&&' (operand types are 's' and 't')
>    38 |   return param_s && param_t;
>       |          ~~~~~~~~^~~~~~~~~~
> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C:38:18: note: candidate: 'operator&&(bool, bool)' <built-in>
> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C:38:18: note:   no known conversion for argument 2 from 't' to 'bool'
>
> This is overly verbose.  Note how the same location has been printed
> three times, obscuring the pertinent messages.
>
> This patch add a new "elide" value to -fdiagnostics-show-location=
> and makes it the default (previously it was "once").  With elision
> the above is printed as:
>
> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C: In function 'int test_3(s, t)':
> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C:38:18: error: no match for 'operator&&' (operand types are 's' and 't')
>    38 |   return param_s && param_t;
>       |          ~~~~~~~~^~~~~~~~~~
>       = note: candidate: 'operator&&(bool, bool)' <built-in>
>       = note:   no known conversion for argument 2 from 't' to 'bool'
>
> where the followup notes are printed with a '=' lined up with
> the source code margin.
>
> Thoughts?

I agree the long pathname in the notes is at first glance redundant
but I'm not sure about using '=' as a shorthand for it.  I have
written many scripts to parse GCC output to extract all diagnostics
(including notes) and publish those on a Web page somewhere, as I'm
sure must have others.  All those scripts would stop working with
this change and require changes to the build system to work again.
Making those changes can be a substantial undertaking in some
organizations.

Have you considered printing just the file name instead?  Or any
other alternatives?

Martin