Thanks! I've committed in r210026 ~Aaron
On Fri, May 30, 2014 at 6:27 PM, Richard Smith <[email protected]> wrote: > 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
