LGTM, thanks!
On Fri, May 30, 2014 at 7:58 AM, Aaron Ballman <[email protected]> wrote: > On Thu, May 29, 2014 at 10:50 PM, Richard Smith <[email protected]> > wrote: > > On Tue, May 27, 2014 at 6:57 AM, Aaron Ballman <[email protected]> > > wrote: > >> > >> The exception-declaration for a function-try-block cannot redeclare a > >> function parameter. One of our existing test cases was XFAILed because > >> of this. This patch is an attempt to fix the issue and un-XFAIL the > >> test. > >> > >> I am getting this from [basic.lookup.unqual]p15, which says, > >> > >> A name used in the handler for a function-try-block (Clause 15) is > >> looked up as if the name was used in the outermost block of the > >> function definition. In particular, the function parameter names shall > >> not be redeclared in the exception-declaration nor in the outermost > >> block of a handler for the function-try-block. > > > > > > This looks like it might do the wrong thing for a function nested within > > another function: > > > > void f(int i) { > > struct S { > > void g() try {} catch (int i) {}; // shouldn't diagnose this, but I > > think you will > > }; > > } > > > > The way we generally handle this is in IdentifierResolver::isDeclInScope, > > and that's the right place for this fix. You should be able to detect a > > catch of a function try block by looking at the flags on the Scope. > > That simplifies things, thank you for the information! New patch > attached, along with updated test case. > > ~Aaron >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
