[PATCH] function try block handler redeclarations

[Richard Smith]

LGTM, thanks!


On Fri, May 30, 2014 at 7:58 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Thu, May 29, 2014 at 10:50 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > On Tue, May 27, 2014 at 6:57 AM, Aaron Ballman <aaron at aaronballman.com>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140530/f213eeef/attachment.html>