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

[Richard Smith]

This is still only producing a warning if 'typename' is followed by
something which isn't a type name in MS mode. We should reject this:

int n; int k = typename n;

On Fri, May 11, 2012 at 11:21 AM, Will Wilson <will at indefiant.com> wrote:

> Hi Richard et al.
>
> Were there any objections/comments/improvements for this updated
> patch? On a purely selfish level it'd be great to get a few of these
> MSExt patches in to avoid juggling too many fixes locally... Although
> maybe I'd better move to git soon :)
>
> Cheers,
> Will.
>
> On 8 May 2012 12:58, Will Wilson <will at indefiant.com> wrote:
> >>>> > 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.
> >
> > Time did allow. The patch is attached using the recursion approach and
> > (on the whole) looks a great deal better. Only
> > Parser::ParseCastExpression() needed updating to ensure it didn't
> > simple assume it got an annotated token back from
> > TryAnnotateTypeOrScopeToken(). All tests pass locally.
> >
> > Cheers,
> > Will.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120511/e144a2b5/attachment.html>