[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776 Ian McInerney changed: What|Removed |Added CC||ian.s.mcinerney at ieee dot org --- Comment #9 from Ian McInerney --- Based on all these examples, it seems like the potential for confusion/incorrect behavior is when the shadowed name is used on the right-hand side of an assignment inside the enum class declaration. So why does this need to trigger if it is just declaring the name and not using it in the enum class declatation? Can this warning instead only warn on a usage in the declaration? e.g. the original example in comment 1 never used foo in the enum class to initialize values in the enum, so where is the possibility for incorrect behavior in this case? Throwing a warning in this case leads to excess warnings in some cases when compiled with headers from MingW, since they tend to define things like RECT, INPUT, OUTPUT, etc. so the shadowing warnings are thrown if you use any of those names in an enum class.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
Sergey Semushin changed:
What|Removed |Added
CC||Predelnik at gmail dot com
--- Comment #8 from Sergey Semushin ---
Encountered this warning and it makes me wonder why there is no warning for
naming variable inside some namespace with the same name as a class in outer
namespace, like:
struct C {};
namespace D
{
int C;
}
This case is very similar to enum class one and I believe it's a lot easier to
somehow be confused here due to shadowing however no warning with Wshadow is
issued this case. Personally I would prefer to not receive warning in both
cases.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
--- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #5)
A better example:
typedef unsigned char foo;
enum class myenum
{
foo,
bar = (foo)-1
};
Is the value -1L or 255?
If I rename myenum::foo to myenum::Foo the code silently changes meaning.
That is a very good example indeed and I don't really know the answer. In an
ideal world we would only warn when ambiguity exists (in the user mind), that
is, at bar = (foo) -1. However, that is probably much more difficult and
expensive than the current warning. So I don't think this is a bug but perhaps
we should add this example to http://gcc.gnu.org/wiki/VerboseDiagnostics
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Jason Merrill jason at gcc dot gnu.org ---
The warning seems correct to me; within the scope of myenum (i.e. in the
initializers of other enumerators) the foo enumerator shadows the global foo.
typedef int foo;
enum class myenum
{
foo,
bar = foo // finds myenum::foo
};
If the order of the typedef and the enum is reversed, there is no warning
because there is no shadowing; in that case, if the foo enumerator had a
different name, the reference in the initializer of bar would just be an error.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #2)
The warning seems correct to me; within the scope of myenum (i.e. in the
initializers of other enumerators) the foo enumerator shadows the global foo.
But the global foo is a type while myenum::foo is not a type. Is there any
context where they can be used interchangeably?
enum class myenum
{
bar = int
};
doesn't make sense.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #3)
But the global foo is a type while myenum::foo is not a type. Is there any
context where they can be used interchangeably?
enum class myenum
{
bar = int
};
doesn't make sense.
How about this:
typedef int foo;
enum class myenum
{
foo = 1,
bar = (foo)+1
};
What is the value of myenum::bar? Is it clear and unambiguous, or should there
be a warning?
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
A better example:
typedef unsigned char foo;
enum class myenum
{
foo,
bar = (foo)-1
};
Is the value -1L or 255?
If I rename myenum::foo to myenum::Foo the code silently changes meaning.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- It also changes meaning if I reorder the declarations of myenum::foo and myenum::bar, which is exactly the sort of fragile code that deserves a warning.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776 Philipp s...@s-e-f-i.de changed: What|Removed |Added CC||jason at redhat dot com --- Comment #1 from Philipp s...@s-e-f-i.de --- CCing Jason because this bug is still unconfirmed. Please tell me if that's ok to do. This issue is still present in gcc-4.8.1 and also on trunk.
