This will be used in rename for doing basic name validation.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
40 ms | linux > Clang.CodeGen::lto-newpm-pipeline.c |
Event Timeline
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
638 | this builds a pretty decent sized hashtable for each call, because LangOpts isn't constant. We could consider exposing getKeywordStatus from IdentifierTable.h, then we could build a StringMap<TokenKind> (once, statically) and then call getKeywordStatus to apply the per-langopts logic. Or we could have cache map from LangOpts to IdentifierTable, since we won't see many sets in practice. Or maybe it doesn't matter, I suppose! | |
clang-tools-extra/clangd/unittests/SourceCodeTests.cpp | ||
794 | demonstrate some sensitivity to langopts? e.g. set CPlusPlus20 to true then check co_await |
address code comments.
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
638 |
this is my impression as well, there are ~120 keywords for C++, I think the number is not too big. |
this builds a pretty decent sized hashtable for each call, because LangOpts isn't constant.
We could consider exposing getKeywordStatus from IdentifierTable.h, then we could build a StringMap<TokenKind> (once, statically) and then call getKeywordStatus to apply the per-langopts logic.
In fact that StringMap might also be generally nice to expose in TokenKinds.h... as long as there are no conflicts.
Or we could have cache map from LangOpts to IdentifierTable, since we won't see many sets in practice.
Or maybe it doesn't matter, I suppose!