This is an archive of the discontinued LLVM Phabricator instance.

[NFCI] Refactor how KeywordStatus is calculated
ClosedPublic

Authored by erichkeane on Aug 2 2022, 11:47 AM.

Details

Summary

The getKeywordStatus function is a horrible mess of inter-dependent 'if'
statements that depend significantly on the ORDER of the checks. This
patch removes the dependency on order by checking each set-flag only
once.

It does this by looping through each of the set bits, and checks each
individual flag for its effect, then combines them at the end.

This might slow down startup performance slightly, as there are only a
few hundred keywords, and a vast majority will only get checked 1x
still.

This patch ALSO removes the KEYWORD_CONCEPTS flag, because it has since
become synonymous with C++20.

Diff Detail

Event Timeline

erichkeane created this revision.Aug 2 2022, 11:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 2 2022, 11:47 AM
erichkeane requested review of this revision.Aug 2 2022, 11:47 AM
aaron.ballman added inline comments.Aug 2 2022, 1:15 PM
clang/include/clang/Basic/TokenKinds.def
400–401
clang/lib/Basic/IdentifierTable.cpp
138–141
169

Should this one be "extension" instead?

173

Is this an extension as well? I'll stop asking individually and just ask generally, when should extension be used?

232

Rather than pretend negating an unsigned value makes sense, can you switch this to use Flags & ~(Flags - 1) instead?

tahonermann accepted this revision.Aug 2 2022, 1:18 PM

I think this looks good. It took me a while to appreciate the new approach; I miss some of the compactness of the previous presentation, but this approach looks more likely to ensure correctness to me.

This revision is now accepted and ready to land.Aug 2 2022, 1:18 PM
erichkeane marked 3 inline comments as done.Aug 2 2022, 1:24 PM
erichkeane added inline comments.
clang/lib/Basic/IdentifierTable.cpp
169

It was not before, and the intent is for this to be NFC:

if (LangOpts.AltiVec && (Flags & KEYALTIVEC)) return KS_Enabled;

I'm not sure the logic that was applied though. The only difference seems to be whether we emit a 'extension used' diagnostic.

173

In this case, when it was before :D I have no idea what our opinion on that is at all though.

aaron.ballman accepted this revision.Aug 2 2022, 1:28 PM

LGTM once nits are fixed (take or leave them).

clang/lib/Basic/IdentifierTable.cpp
169

Okay, given that the goal of this is NFC, I'm happy enough.

erichkeane updated this revision to Diff 449404.Aug 2 2022, 1:29 PM
erichkeane marked 3 inline comments as done.

Add underlying type to TokenKey, plus did all of Aaron's review comments.

In general, I think we dont' have a good definition of Extension vs Enabled here,
and someone should probably think that through. I'll review anything anyone has :D

tahonermann accepted this revision.Aug 2 2022, 1:38 PM

Accepting again. New changes suggested by Aaron are a clear improvement. Except maybe for the rename of LSB to LSSB. LSSB is what? Low-Speed Serial Bus? Law School Student Body? Lone Star Symphonic Band? Maybe just call it Flag.

Accepting again. New changes suggested by Aaron are a clear improvement. Except maybe for the rename of LSB to LSSB. LSSB is what? Low-Speed Serial Bus? Law School Student Body? Lone Star Symphonic Band? Maybe just call it Flag.

Was going for "Least Significant Set Bit", which I clearly missed. I'll come up with something better before committing. Thanks!

This revision was landed with ongoing or failed builds.Aug 3 2022, 6:41 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2022, 6:41 AM
labath added a subscriber: labath.Aug 3 2022, 7:05 AM

This seems to break lldb tests, specifically the compilation of this source file.

The compile fails with an assertion (Keyword not known to come from a newer Standard or proposed Standard), so I am assuming that change was not intentional.

This seems to break lldb tests, specifically the compilation of this source file.

The compile fails with an assertion (Keyword not known to come from a newer Standard or proposed Standard), so I am assuming that change was not intentional.

It was not, thanks for the heads up. Looking into it now.

This seems to break lldb tests, specifically the compilation of this source file.

The compile fails with an assertion (Keyword not known to come from a newer Standard or proposed Standard), so I am assuming that change was not intentional.

It was not, thanks for the heads up. Looking into it now.

I see the problem now, patch incoming as soon as I validate it locally. char8_t was mis-reported as 'future' in C mode, so I was missing a condition.

This seems to break lldb tests, specifically the compilation of this source file.

The compile fails with an assertion (Keyword not known to come from a newer Standard or proposed Standard), so I am assuming that change was not intentional.

It was not, thanks for the heads up. Looking into it now.

I see the problem now, patch incoming as soon as I validate it locally. char8_t was mis-reported as 'future' in C mode, so I was missing a condition.

Fix committed in: bf6db18e52815475baebff2c330763fedac6b5e4

This breaks clang causes it to crash in LLDB buildbot testsuite breaking the LLDB buildbot: https://lab.llvm.org/buildbot/#/builders/96/builds/27003

This breaks clang causes it to crash in LLDB buildbot testsuite breaking the LLDB buildbot: https://lab.llvm.org/buildbot/#/builders/96/builds/27003

I believe this was already resolved by https://github.com/llvm/llvm-project/commit/bf6db18e52815475baebff2c330763fedac6b5e4 -- the current failures seem unrelated to the previous one. e.g., https://lab.llvm.org/buildbot/#/builders/96/builds/27020

This breaks clang causes it to crash in LLDB buildbot testsuite breaking the LLDB buildbot: https://lab.llvm.org/buildbot/#/builders/96/builds/27003

I believe this was already resolved by https://github.com/llvm/llvm-project/commit/bf6db18e52815475baebff2c330763fedac6b5e4 -- the current failures seem unrelated to the previous one. e.g., https://lab.llvm.org/buildbot/#/builders/96/builds/27020

Yep, this is the same break I fixed that @labath alerted me to just above this discussion.