[PATCH] function try block handler redeclarations

[Aaron Ballman]

Thanks! I've committed in r210026

~Aaron

On Fri, May 30, 2014 at 6:27 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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
>
>