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

[Will Wilson]

>> > You should consume the 'typename' token, and try to recover as if the
>> > 'typename' keyword were not present, following the logic present later
>> > on in
>> > that function. As a special case, if that later logic were to find that
>> > the
>> > tokens after the 'typename' keyword can't be annotated as a type name,
>> > you
>> > should produce a hard error (even with MS extensions enabled).
>> >
>> > (In particular, for 'typename identifier', it will be the identifier you
>> > annotate, not the 'typename' keyword.)
>>
>> Sorry for the delay! I've attached an updated patch (with test cases)
>> that seems to do the job. I've also had to update two other tests to
>> allow for the different code paths (and thus different errors)
>> followed due to the attempt at recovering from the error.
>>
>> All tests pass locally. It'd be great if some other people could
>> verify it as well.
>
>
> A few things: This is still only producing a warning if 'typename' is
> followed by something which isn't a type name in MS mode. That needs to be
> fixed to produce an error in that case. Also, it would be great to apply
> typo correction in this case, and to avoid duplicating the code from the
> second half of the function.

Thanks for giving it the once over.

Fair point on the error in MS mode, I'll rework it.

I agree the code duplication in TryAnnotateTypeOrScopeToken is less
than optimal (I'll try the recursive approach you've suggested below).
The typo-correction sounds promising - if I get a change though I'll
investigate further (with the sound of deadlines rushing by ;).

> How about just recursively calling TryAnnotateTypeOrScopeToken after
> consuming the invald 'typename' token, then emitting the error diagnostic if
> it fails or we're not in MS mode, and the warning diagnostic otherwise?

That actually looks like a promising approach... I'll give it a shot
tomorrow if time allows.

Cheers,
Will.