[cfe-commits] [patch] fix for crash-on-invalid when recovering from an invalid variable name & deduced array dimension in C++11

[David Blaikie]

On Tue, Feb 14, 2012 at 12:59 AM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Tue, Feb 14, 2012 at 12:39 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> The patch/example is easier to understand than the description, perhaps.
>>
>> struct foo {
>>  operator int[](){};
>
>
> Playing with lambdas, hmm? ;-)

they've got to be somewhere in Clang, right? (actually I'll blame Lang
for finding this test case ;))

>
>>
>> };
>>
>> crashes - clang seems to be parsing 'operator int' as a member
>> variable name (? why is that? no type was provided before the name,
>> and it seems hardly likely a user would've mistakenly tried to name
>> their variable 'operator int' & much more likely they've messed up a
>> member function definition), sees the {} thinking its an in-class
>> initializer and the [] a deduced array bound. At this point the parser
>> tries to invalidate the declaration which is non-existent because of
>> the bogus name, and dereferences null.
>>
>> Add the null check (there's a smattering of similar checks littered
>> around this area, so that seems like a reasonable solution - the
>> erroneous error recovery highlighted above not withstanding).
>
>
> LGTM

Thanks, committed as r150464

>
> That said, I think we should be able to do a lot better on this case. We
> give a terrible diagnostic even in cases which are much more plausible:
>
> <stdin>:1:26: error: C++ requires a type specifier for all declarations
> struct S { operator int(&)[4](); };
>                         ~^
> <stdin>:1:27: error: 'type name' declared as array of functions of type 'int
> ()'
> struct S { operator int(&)[4](); };
>                           ^
> <stdin>:1:12: error: conversion function cannot have any parameters
> struct S { operator int(&)[4](); };
>            ^

Agreed - I tried that exact test case & was similarly dismayed at how
far down the wrong rabbit hole Clang goes. Thanks for the
validation/verification that my expectation was on the right track.

- David