Anonymous records with typedef names for linkage

[Richard Smith]

On Wed Jan 29 2014 at 3:05:34 PM, John McCall <rjmccall at apple.com> wrote:

> On Jan 29, 2014, at 8:45 AM, Richard Smith <richard at metafoo.co.uk> wrote:
> > When we see the class definition, we already have to cache the tokens in
> member functions until we hit the close brace. It doesn't seem too hard or
> expensive to look ahead and see if we have a typedef name for linkage
> purposes if the class is anonymous and is preceded or followed by typedef.
>
> I don't think we can actually tentatively parse declarators.  Remember
> that we might have something like
>
>   typedef struct { ... } (*FnType)(), (*ArrayType)[sizeof(decltype(declval<FnType>()()))],
> StructType;
>
> because C++ is dumb.
>
> But obviously we could recognize some simple cases and limit the damage of
> my proposed diagnostic.
>

Your example doesn't seem to show a problem (since we're just looking to
see if there's any declarator with nothing more interesting than parens
around the declarator-id). I can imagine trouble with something like this,
though:

typedef struct { ... } *A, X<Y<A>::Z < Q>::*foo, S;

(because we don't know if the < after 'Z' begins a template-argument-list
or not). Yes, this may be infeasible.

> Can this go wrong in any non-delay-parsed context?
>
> 'this' is legal in some non-delay-parsed contexts, namely trailing result
> types.
>
> Do you have any objection to adopting my proposed diagnostic as a
> semi-temporary fix?  All the code it would affect currently triggers an
> assertion, and frankly it feels like a "real" fix here would require a
> pretty disproportionate amount of effort for the expected benefit.


I'm fine with it right up until people start filing bugs saying we broke
them ;-)

Honestly, I think your approach of a diagnostic in this case is not only
reasonable, it's a reasonable thing to propose as a DR, assuming it doesn't
break the world.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140129/b6e6cdb6/attachment.html>