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 ^
next 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: linkBe 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).