Anonymous records with typedef names for linkage

Richard Smith metafoo at
Wed Jan 29 15:32:06 PST 2014

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

> On Jan 29, 2014, at 8:45 AM, Richard Smith <richard at> 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,

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: <>

More information about the cfe-commits mailing list