According to the C++ standard, clause 3.3.2, paragraph 2, sentence 3, the following program should be invalid: int foo (int bar) try { return 0; } catch (...) { int bar = 0; // invalid return 1; } Specifically, `bar' may not be redeclared in the outermost block of a handler in a function try-block. GCC 4.1.1 gives no errors or warnings (other than unused parameters and variables).
Poor man's workaround: -Wshadow -Werror
Another example perhaps? void foo() { try { } catch (void *e) { void *e; // invalid } } The C++ standard, clause 3.3.2 paragraph 3, states that catch exception-declarations may not be redeclared in the outermost block of the catch block.
Confirmed.
It gets worse :( The following example used to be detected by GCC 4.1.1, but is now permitted by GCC 4.1.2, 4.2.1, 4.2.2, and 4.3-20071026, and hence is a regression. int foo (int bar) try { return 0; } catch (int bar) // invalid { return 1; } -Wshadow still detects it, but it is no longer an error.
still not solved at 4.3.4
Comment #2 is PR5605. Comparing to Janis' fix for PR2288 (http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00838.html) looks like the pushdecl_maybe_friend_1 checks must be beefed up, maybe we need an additional sk_* for Comment #2. Seems doable. Adding Janis in CC in case she wants to beat me (or somebody else) on this.
*** Bug 5605 has been marked as a duplicate of this bug. ***
On it.
Jason, I'm on this issue but I'm not sure how we want to resolve it. After Janis' patch (see Comment #6) in pushdecl_maybe_friend_1 we issue hard errors for some kinds of shadowings but not for others. For comparison, clang issues hard errors for all three testcases here, ICC warnings (like current GCC). If we wanted, I could tweak the parser to carefully do_pushlevel (sk_catch) and therefore change to errors only the specific shadowings at issue in this PR, but I'm also aiming for some consistency.
(In reply to Paolo Carlini from comment #9) > After Janis' patch (see Comment #6) in pushdecl_maybe_friend_1 we issue hard > errors for some kinds of shadowings but not for others. For comparison, > clang issues hard errors for all three testcases here, ICC warnings (like > current GCC). If we wanted, I could tweak the parser to carefully > do_pushlevel (sk_catch) and therefore change to errors only the specific > shadowings at issue in this PR, but I'm also aiming for some consistency. Well, the language requires diagnostics for some shadowings and not others, so it makes sense for us to mirror that. But we probably want permerror rather than error.
Fixed for 4.9.0.