public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name
@ 2022-01-12 18:13 nightstrike at gmail dot com
2022-01-12 18:15 ` [Bug c/103996] " pinskia at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: nightstrike at gmail dot com @ 2022-01-12 18:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103996
Bug ID: 103996
Summary: Enhancement: Better diagnostic for invalid reuse of a
function name
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Related email thread:
https://gcc.gnu.org/pipermail/gcc-help/2022-January/141117.html
I recently hit this problem:
#include <strings.h>
void f() {
index[0] = 0;
}
#gcc is 11.2.0
gcc -c a.c
a.c:4:7: error: subscripted value is neither array nor pointer nor vector
4 | index[1] = 0;
| ^
I could not find a compiler option that would tell me what the root cause was.
I wasn't getting a simple "undeclared" error, so I surmised the name must
already be in use, but I was confused as to how or where it was being used. My
first thought was that maybe index was a global variable, so I tried using
-Wshadow. Eventually, I found that it was a function from strings.h which was
included several layers down an include spiral.
I think an effective note from gcc such as "index was previously declared here
as a function", or something similar that often happens in other diagnostics,
would aid in finding the root cause of my bug.
Incidentally, in my actual scenario, the real bug was that I forgot to access
index as a member of a struct: x.index vs index. But I'd wager that expecting
GCC to look for all nearby structs for a similarly named member is
unreasonable. Simply telling me where index originates, though, would have
helped greatly.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c/103996] Enhancement: Better diagnostic for invalid reuse of a function name
2022-01-12 18:13 [Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name nightstrike at gmail dot com
@ 2022-01-12 18:15 ` pinskia at gcc dot gnu.org
2022-01-12 18:23 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-01-12 18:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103996
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
C++ front-end produces:
<source>: In function 'void f()':
<source>:4:10: error: invalid types '<unresolved overloaded function
type>[int]' for array subscript
4 | index[0] = 0;
| ^
Which seems better.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c/103996] Enhancement: Better diagnostic for invalid reuse of a function name
2022-01-12 18:13 [Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name nightstrike at gmail dot com
2022-01-12 18:15 ` [Bug c/103996] " pinskia at gcc dot gnu.org
@ 2022-01-12 18:23 ` pinskia at gcc dot gnu.org
2022-01-12 18:38 ` [Bug c/103996] Provide " pinskia at gcc dot gnu.org
2022-01-13 11:40 ` egallager at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-01-12 18:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103996
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-01-12
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Simplified testcase:
void f(void);
int main(void)
{
f[0] = 0;
}
The C++ front-end for the above testcase produces:
<source>: In function 'int main()':
<source>:4:8: warning: pointer to a function used in arithmetic
[-Wpointer-arith]
4 | f[0] = 0;
| ^
<source>:4:10: error: assignment of read-only location '* f'
4 | f[0] = 0;
| ~~~~~^~~
For a slightly different one:
void f(void);
void f(int);
int main(void)
{
f[0] = 0;
}
The C++ fornt-end produces similar to what was done in the index case.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c/103996] Provide Better diagnostic for invalid reuse of a function name
2022-01-12 18:13 [Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name nightstrike at gmail dot com
2022-01-12 18:15 ` [Bug c/103996] " pinskia at gcc dot gnu.org
2022-01-12 18:23 ` pinskia at gcc dot gnu.org
@ 2022-01-12 18:38 ` pinskia at gcc dot gnu.org
2022-01-13 11:40 ` egallager at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-01-12 18:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103996
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Enhancement: Better |Provide Better diagnostic
|diagnostic for invalid |for invalid reuse of a
|reuse of a function name |function name
Severity|normal |enhancement
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c/103996] Provide Better diagnostic for invalid reuse of a function name
2022-01-12 18:13 [Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name nightstrike at gmail dot com
` (2 preceding siblings ...)
2022-01-12 18:38 ` [Bug c/103996] Provide " pinskia at gcc dot gnu.org
@ 2022-01-13 11:40 ` egallager at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: egallager at gcc dot gnu.org @ 2022-01-13 11:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103996
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=87656
CC| |egallager at gcc dot gnu.org
--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
So, -Wshadow actually used to warn about this, but people didn't like it, so
that part of -Wshadow got removed from GCC in 4.8:
https://gcc.gnu.org/gcc-4.8/changes.html
See also: https://lkml.org/lkml/2006/11/28/239
However, as of GCC 7, the -Wshadow flag now takes additional arguments
(-Wshadow=global, -Wshadow=local, -Wshadow=compatible-local) to let users be
more specific about which shadowing warnings they want:
https://gcc.gnu.org/gcc-7/changes.html
So, I'm wondering if the part of -Wshadow that got removed in 4.8 could get
added back to it as a non-default argument to the flag? e.g. -Wshadow=function
And maybe the arguments to -Wshadow could become a comma-separated list, too,
so users could do things like -Wshadow=function,global or
-Wshadow=function,local or something (in bug 87656 I was thinking that a
-Wshadow=compatible-global might make sense, too)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-01-13 11:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-12 18:13 [Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name nightstrike at gmail dot com
2022-01-12 18:15 ` [Bug c/103996] " pinskia at gcc dot gnu.org
2022-01-12 18:23 ` pinskia at gcc dot gnu.org
2022-01-12 18:38 ` [Bug c/103996] Provide " pinskia at gcc dot gnu.org
2022-01-13 11:40 ` egallager at gcc dot gnu.org
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).