public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "achurch+gcc at achurch dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/65466] New: Unnecessary source line output for "note: each undeclared identifier is reported only once"
Date: Thu, 19 Mar 2015 01:18:00 -0000	[thread overview]
Message-ID: <bug-65466-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466

            Bug ID: 65466
           Summary: Unnecessary source line output for "note: each
                    undeclared identifier is reported only once"
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: achurch+gcc at achurch dot org

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
                ^


             reply	other threads:[~2015-03-19  1:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19  1:18 achurch+gcc at achurch dot org [this message]
2015-03-20  0:02 ` [Bug c/65466] " joseph at codesourcery dot com
2015-03-20  2:51 ` manu at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-65466-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).