[cfe-commits] [PATCH] Allow typedef with unnecessary "typename" when ms-extensions are enabled.

[Richard Smith]

On Sun, Dec 9, 2012 at 1:54 PM, Will Wilson <will at indefiant.com> wrote:
> After looking at the problem a while longer, I've tried an approach
> which is simple if not a little nasty in
> Parser::TryAnnotateTypeOrScopeToken():
>
> // >>>> clang\lib\Parse\Parser.cpp line 1481 <<<<
>     if (!SS.isSet()) {
>
>       // MS compatibility: typename can appear before CV-qualifiers
>       if (getLangOpts().MicrosoftExt && isTypeQualifier()) {
>         Diag(Tok.getLocation(), diag::warn_expected_qualified_after_typename);
>         // Ignore the typename token
>         return false;
>       }
>
>       if (Tok.is(tok::identifier) || Tok.is(tok::annot_template_id) ||
>           Tok.is(tok::annot_decltype)) {
> [...]
>
> This works for simple cases, but obviously looses the meaning of the
> typename keyword which would impact any occurrences of annotated or
> scoped types thereafter. That said, given this is MicrosoftExt
> specific and it allows a little more existing code to compile without
> too much code churn perhaps it's a reasonable approach? It doesn't
> solve all of the MS compat issues in this area but it's a small
> improvement after all.

So, a couple of questions. Firstly, do you have an idea how common
this pattern is? Do we need to be compatible with platform headers, or
only for user code which uses those headers? Secondly, are there real
cases where this patch doesn't go far enough (that is, where we
actually need the 'typename' keyword to disambiguate something)? I
*suspect* this patch will be fine in practice, because the 'typename'
should be enough for any disambiguation, and once we know we're
parsing a type, we shouldn't need the 'typename' keyword.

> If it's not too disgusting, let me know and I'll knock up a patch with
> test cases...

I have some concerns over the details of the implementation -- in
particular, because you're not producing an annotation token,
TryAnnotateTypeOrScopeToken could get called multiple times for the
same 'typename' token (in a tentative parse then later in a full
parse), resulting in duplicated diagnostics.