[PATCH] Start to unify contextual keywords

[Alp Toker]

Landed in r197496 with the extra check.

Will be looking to unify handling of virt-specifiers, altivec and objc 
context-sensitive keywords next, and then revisit this when we have an 
idea of how it all fits together.

So far I've got a preliminary annotator for virt-specifiers and the 
results are promising, with a small bonus that we'll soon have syntax 
highlighting for all contextual keywords :-)

Alp.


On 13/12/2013 14:02, Alp Toker wrote:
>
> On 12/12/2013 20:47, Richard Smith wrote:
>> I like the simplification here.
>>
>> +  if (TagType == DeclSpec::TST_struct && Tok.isNot(tok::identifier)) {
>> +    const IdentifierInfo *II = Tok.getIdentifierInfo();
>>
>> This will assert if there's an annotation token here (that might 
>> happen if we've done some tentative parsing and annotated a nested 
>> name specifier).
>
> Good catch. I'll shore it up.
>
>>
>>
>> The reverting-and-unreverting mechanism here seems unsatisfying. 
>> Perhaps we should redesign this somewhat. How about changing the 
>> semantics to be simply that these tokens are always normal 
>> identifiers, except when they're followed by a left paren (in the 
>> case where your patch calls TryIdentKeywordUpgrade).
>>
>> Specifically, something like: change the RevertedTokenID flag on 
>> Token to a ContextualKeyword flag or similar, set the kind to 
>> tok::identifier by default for these traits, and generate a 
>> StringSwitch in TryIdentKeywordUpgrade to pick the right kind. Then 
>> we can drop the TryKeywordIdentFallback hack entirely -- the 
>> semantics would be simply that these identifiers are normal 
>> identifiers unless they're followed by a left paren.
>
> Agree that it's unsatisfying. I've encapsulated the behaviour into 
> these two functions exactly so we can experiment with techniques like 
> that.
>
> The approach you describe makes sense for many of the contextual 
> keywords, but for type traits specifically I suspect it may make sense 
> to tidy and refine the current approach. If we end up making these 
> names globally available as identifiers, user code is going to start 
> using them and that's going to become a portability headaches. So it 
> could go either way but I'd like to investigate that on a separate 
> schedule, tending towards "less magic" for now.
>
> Either solution should help put an end to the cat-and-mouse game 
> between libc++, libstdc++, MSVC and Embarcadero fighting over the 
> __is_ and __has_ namespace.
>
> Let's revisit this once I've unified the other kinds of 
> context-sensitive keywords so we can compare the merits of each approach.
>
> Alp.
>
>
>
>
>
>>
>>
>> On Thu, Dec 12, 2013 at 6:46 AM, Alp Toker <alp at nuanti.com 
>> <mailto:alp at nuanti.com>> wrote:
>>
>>     Hi,
>>
>>     Now that we emit diagnostics for keyword-as-identifier hacks
>>     (-Wkeyword-compat) we can go ahead and simplify some of the old
>>     revertible keyword support.
>>
>>     This patch adds a TryIdentKeywordUpgrade() function to mirror the
>>     recently added TryKeywordIdentFallback(), and uses it to replace
>>     hard-coded REVERTIBLE_TYPE_TRAITs.
>>
>>     The mid-term goal is to work with libc++ to remove dependence on
>>     the GNU token hacks, and to unify context-sensitive keyword
>>     handing in the C++ frontend.
>>
>>      4 files changed, 43 insertions(+), 70 deletions(-)
>>
>>     Alp.
>>
>>     --     http://www.nuanti.com
>>     the browser experts
>>
>>
>>     _______________________________________________
>>     cfe-commits mailing list
>>     cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>

-- 
http://www.nuanti.com
the browser experts