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

[Richard Smith]

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? ;-)


> };
>
> 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

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](); };
           ^

- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120214/2f8997e3/attachment.html>