For the first undeclared identifier found in a source file, GCC outputs an additional diagnostic, "note: each undeclared identifier is reported only once for each function it appears in", and then (assuming no -fno-diagnostics-show-caret) displays the source line and location of the undeclared identifier. The note itself is fine, but the source location only clutters up the output since it was already displayed for the actual warning. This is exacerbated if the undeclared identifier was used in a macro, since the macro expansion is also printed twice (as in the example below). It seems to me it would make more sense to either suppress the source line display and macro expansion for the "note: each undeclared..." diagnostic, or merge that text into the warning text for the first instance of the warning, perhaps: "'bar' undeclared (first use in this function; each undeclared identifier is reported only once for each function it appears in)". $ cat foo.c #define FOO(x) x int foo(void) {return FOO(bar);} $ gcc-4.9.2 -c foo.c foo.c: In function 'foo': foo.c:2:27: error: 'bar' undeclared (first use in this function) int foo(void) {return FOO(bar);} ^ foo.c:1:16: note: in definition of macro 'FOO' #define FOO(x) x ^ foo.c:2:27: note: each undeclared identifier is reported only once for each function it appears in int foo(void) {return FOO(bar);} ^ foo.c:1:16: note: in definition of macro 'FOO' #define FOO(x) x ^
I implemented some finer-control for the caret in https://gcc.gnu.org/ml/gcc-patches/2012-04/msg01836.html that specifically fixed this case. However, I never got around to get it approved and committed it. Please, feel free to take that patch and get it reviewed and committed. (If I was re-doing that patch again, I will try to overload inform(), because inform_with_flags is just too much typing).
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: > (If I was re-doing that patch again, I will try to overload inform(), because > inform_with_flags is just too much typing). Note that diagnostic functions cannot be overloaded in a way that means different functions with the same name have the msgid argument in different positions, as that breaks exgettext.
(In reply to joseph@codesourcery.com from comment #2) > On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: > > > (If I was re-doing that patch again, I will try to overload inform(), because > > inform_with_flags is just too much typing). > > Note that diagnostic functions cannot be overloaded in a way that means > different functions with the same name have the msgid argument in > different positions, as that breaks exgettext. Ah, yes, I forgot about this. We had this problem already in the Fortran FE. Can exgettext be fixed to handle overloads eventually? Perhaps someone could reimplement it as a GCC plugin. That would be a nice GSoC!
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 > > --- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- > (In reply to joseph@codesourcery.com from comment #2) > > On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: > > > > > (If I was re-doing that patch again, I will try to overload inform(), because > > > inform_with_flags is just too much typing). > > > > Note that diagnostic functions cannot be overloaded in a way that means > > different functions with the same name have the msgid argument in > > different positions, as that breaks exgettext. > > Ah, yes, I forgot about this. We had this problem already in the Fortran FE. > Can exgettext be fixed to handle overloads eventually? Perhaps someone could > reimplement it as a GCC plugin. That would be a nice GSoC! exgettext (which essentially just computes arguments to pass to xgettext from GNU gettext) needs to handle sources that are not part of the current configuration, including inside disabled #if conditionals. That is, the sources parsed by the compiler compiling any particular build of GCC are not the full set of sources that need to be handled to generate gcc.pot.