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 <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
