On Tue, Feb 14, 2012 at 12:39 AM, David Blaikie <[email protected]> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
