Anonymous records with typedef names for linkage

[Richard Smith]

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

> On Jan 29, 2014, at 3:32 PM, Richard Smith <metafoo at gmail.com> wrote:
>
> 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.
>
>
> My example was just to show that we'd need tentative parsing to handle
> declaring new names, but yes, yours much more clearly shows that we'd need
> to perform arbitrary instantiation.
>
>  > 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 ;-)
>
>
> At which point you'll stab me in the back and declare yourself for The
> People, got it. :)
>
> 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.
>
>
> I'm not sure what a reasonable formal rule here would be, but if you can
> think of one, that sounds great.  Using 'this' in a non-delayed context in
> an anonymous type that later receives a typedef name for linkage purposes?
>  That would require us to parse the declarators before doing the delayed
> parsing, which is awkward because those names (1) do have to be in scope
> during subsequent declarators but (2) can't be in scope (including
> qualified scope) during the delayed parsing, but that's certainly more
> feasible than completely reworking stuff to not do any linkage queries.
>

The examples I've seen so far all rely on us needing to compute the linkage
of the type when it's used as a template argument (which, incidentally, the
standard does *not* currently require, but see core issue 1602). Are there
other cases that we care about?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140130/1cd06b0b/attachment.html>