<div class="gmail_quote">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:</div><div class="gmail_quote"><br></div><div class="gmail_quote">
int n; int k = typename n;</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, May 11, 2012 at 11:21 AM, Will Wilson <span dir="ltr"><<a href="mailto:will@indefiant.com" target="_blank">will@indefiant.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard et al.<br>
<br>
Were there any objections/comments/improvements for this updated<br>
patch? On a purely selfish level it'd be great to get a few of these<br>
MSExt patches in to avoid juggling too many fixes locally... Although<br>
maybe I'd better move to git soon :)<br>
<br>
Cheers,<br>
Will.<br>
<div class="HOEnZb"><div class="h5"><br>
On 8 May 2012 12:58, Will Wilson <<a href="mailto:will@indefiant.com">will@indefiant.com</a>> wrote:<br>
>>>> > You should consume the 'typename' token, and try to recover as if the<br>
>>>> > 'typename' keyword were not present, following the logic present later<br>
>>>> > on in<br>
>>>> > that function. As a special case, if that later logic were to find that<br>
>>>> > the<br>
>>>> > tokens after the 'typename' keyword can't be annotated as a type name,<br>
>>>> > you<br>
>>>> > should produce a hard error (even with MS extensions enabled).<br>
>>>> ><br>
>>>> > (In particular, for 'typename identifier', it will be the identifier you<br>
>>>> > annotate, not the 'typename' keyword.)<br>
>>>><br>
>>>> Sorry for the delay! I've attached an updated patch (with test cases)<br>
>>>> that seems to do the job. I've also had to update two other tests to<br>
>>>> allow for the different code paths (and thus different errors)<br>
>>>> followed due to the attempt at recovering from the error.<br>
>>>><br>
>>>> All tests pass locally. It'd be great if some other people could<br>
>>>> verify it as well.<br>
>>><br>
>>><br>
>>> A few things: This is still only producing a warning if 'typename' is<br>
>>> followed by something which isn't a type name in MS mode. That needs to be<br>
>>> fixed to produce an error in that case. Also, it would be great to apply<br>
>>> typo correction in this case, and to avoid duplicating the code from the<br>
>>> second half of the function.<br>
>><br>
>> Thanks for giving it the once over.<br>
>><br>
>> Fair point on the error in MS mode, I'll rework it.<br>
>><br>
>> I agree the code duplication in TryAnnotateTypeOrScopeToken is less<br>
>> than optimal (I'll try the recursive approach you've suggested below).<br>
>> The typo-correction sounds promising - if I get a change though I'll<br>
>> investigate further (with the sound of deadlines rushing by ;).<br>
>><br>
>>> How about just recursively calling TryAnnotateTypeOrScopeToken after<br>
>>> consuming the invald 'typename' token, then emitting the error diagnostic if<br>
>>> it fails or we're not in MS mode, and the warning diagnostic otherwise?<br>
>><br>
>> That actually looks like a promising approach... I'll give it a shot<br>
>> tomorrow if time allows.<br>
><br>
> Time did allow. The patch is attached using the recursion approach and<br>
> (on the whole) looks a great deal better. Only<br>
> Parser::ParseCastExpression() needed updating to ensure it didn't<br>
> simple assume it got an annotated token back from<br>
> TryAnnotateTypeOrScopeToken(). All tests pass locally.<br>
><br>
> Cheers,<br>
> Will.<br>
</div></div></blockquote></div><br>