[Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name

[Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name

[nightstrike at gmail dot com]

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.

[Bug c/103996] Enhancement: Better diagnostic for invalid reuse of a function name

[pinskia at gcc dot gnu.org]

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.

[Bug c/103996] Enhancement: Better diagnostic for invalid reuse of a function name

[pinskia at gcc dot gnu.org]

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.

[Bug c/103996] Provide Better diagnostic for invalid reuse of a function name

[pinskia at gcc dot gnu.org]

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

[Bug c/103996] Provide Better diagnostic for invalid reuse of a function name

[egallager at gcc dot gnu.org]

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)