[cfe-dev] Patch: Re: -Wshadow rationale for data members

Adam Nohejl adam+clang at nohejl.name
Fri Nov 12 12:48:20 PST 2010


On 2010/11/12, at 19:11, John McCall wrote:

>> Enum constants are little different from variables/static data variables: they can be defined at the same places, have the same scoping rules, and can mostly be used in the same syntactic context (of course there's no storage associated with enum constants).
> 
>> I can't see why there should be any difference between how x's and y's are handled in the following:
> 
> I am primarily worried about flooding the world with -Wshadow warnings that we, and gcc, have never emitted before.

Yes, it certainly shouldn't be overdone. One bad example is reporting shadowed functions. Thanks to overzealous -Wshadow in some old release of GCC I know that there's an index() function somewhere in the standard C headers;).

> On the other hand, I don't personally enable -Wshadow, and it's not part of -Wall, and I can't deny the inconsistency, so if you think that -Wshadow should warn about shadowing enumerators (treating them as static variables when they're class members) then we can try that experiment.

A small supportive argument is that GCC already takes enums into account (although not consistently). It does so at least since version 4.0 and I haven't been able to find any complaints on the web.

Incidentally I also found this in GCC 4.6 release notes: "The -Wshadow option now warns if a local variable or type declaration shadows another type in C++. Note that the compiler will not warn if a local variable shadows a struct/class/enum, but will warn if it shadows an explicit typedef."

So I guess that we're still being quite conservative. Anyway, I'll try doing the non-enum stuff first and wait if there are any more comments on this.

Have a nice weekend,

-- 
Adam





More information about the cfe-dev mailing list