[PATCH] D146148: [clang] Add a namespace for interesting identifiers.

Zahira Ammarguellat via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 21 10:52:15 PDT 2023


zahiraam marked an inline comment as done.
zahiraam added inline comments.


================
Comment at: clang/lib/Sema/SemaDecl.cpp:6784
+      if (II->getInterestingIdentifierID() != 0)
+        NewTD->addAttr(AvailableOnlyInDefaultEvalMethodAttr::Create(Context));
     }
----------------
rjmccall wrote:
> zahiraam wrote:
> > rjmccall wrote:
> > > Please switch over the interesting identifiers here; we don't want to assume this feature is only used for these two names.
> > > 
> > > In fact, should we go ahead and immediately apply it to the four identifiers above this?  That would be nice, because then we could actually do this in two patches: one patch that does the refactor to track interesting identifiers but doesn't cause any functionality changes and a second, very small patch that just introduces the new special treatment for `float_t` and `double_t`.
> > > Please switch over the interesting identifiers here; we don't want to assume this feature is only used for these two names.
> > > 
> > > In fact, should we go ahead and immediately apply it to the four identifiers above this?  That would be nice, because then we could actually do this in two patches: one patch that does the refactor to track interesting identifiers but doesn't cause any functionality changes and a second, very small patch that just introduces the new special treatment for `float_t` and `double_t`.
> > 
> > Are you saying that "FILE", "jmp_buf"," sigjmp_buf" and "ucontext_t" are also interesting identifiers? If yes, they should be added to the list of interesting identifiers in TokenKinds.def?
> Right.  The basic idea of interesting identifiers is to replace these sorts of identifier comparisons in performance-critical code.  So your first patch would *only* add those four identifiers as interesting identifiers, handling them here by registering the `typedef` with the ASTContext like the code is already doing.  Then you'd make a follow-up patch that adds `float_t` and `double_t` and handles them here by implicitly adding your new attribute.
> Right.  The basic idea of interesting identifiers is to replace these sorts of identifier comparisons in performance-critical code.  So your first patch would *only* add those four identifiers as interesting identifiers, handling them here by registering the `typedef` with the ASTContext like the code is already doing.  Then you'd make a follow-up patch that adds `float_t` and `double_t` and handles them here by implicitly adding your new attribute.

I think that does it?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146148/new/

https://reviews.llvm.org/D146148



More information about the cfe-commits mailing list