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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
