This uses the fast-check allowlist added in the previous commit.
This is behind a config option to allow users/developers to enable checks
we haven't timed yet, and to allow the --check-tidy-time flag to work.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Ideas on testing welcome. Does it make sense to rely on the fact that misc-const-correctness is always slow? :-D
I'd say it doesn't, if the check is ever updated in a way to be more performant it'd be nice if we don't need to change anything hard coded in clangd to enable it to run again.
clang-tools-extra/clangd/ParsedAST.cpp | ||
---|---|---|
546 | Not exactly related but surely both check factories could be made into static variables and then just choose the factory based on the config. | |
clang-tools-extra/clangd/tool/Check.cpp | ||
492 | How about changing this provide to always enable slow checks, but only use the provider if the flag is passed? |
clang-tools-extra/clangd/ParsedAST.cpp | ||
---|---|---|
546 | createChecks is nonconst, so this requires some fast-and-loose assumptions about nonconst operations being threadsafe. (In principle you're right, but I think this is mostly an argument that ClangTidyCheckFactories and its adjacent APIs could be improved, which isn't something I can get sidetracked by at the moment) | |
clang-tools-extra/clangd/tool/Check.cpp | ||
492 | This doesn't seem like it would simplify the code, but it does mean that if --check wants to override other config options then we'd need to add a second provider. |
i can't think of a proper way to test this out either. unless we somehow let slow-tidy-check list to be configurable, so probably fine to make sure it works locally and hope that new people introducing tidy checks do complain.
clang-tools-extra/clangd/ConfigCompile.cpp | ||
---|---|---|
558 | nit: drop has_value? | |
clang-tools-extra/clangd/TidyProvider.cpp | ||
307 | should we update callers here to also emit a warning when they're turning on a slow check (and possibly mention SlowChecks override?) this might as well be our way of testing this to some extent. we'd still rely on a certain check-name always being part of the list (and pick a new element whenever we're updating the list), but at least we wouldn't rely on semantics of the check (i.e. also have a test case that'd trigger the warning). | |
clang-tools-extra/clangd/tool/Check.cpp | ||
492 | i think it's better to always have the provider, in case we decide to override more options later on (it'd be nice if we didn't come up with a new provider for every option we override). but seems fine either way for now. |
clang-tools-extra/clangd/ConfigCompile.cpp | ||
---|---|---|
558 | This is a boolean, so there's an obvious+wrong interpretation of that version. | |
clang-tools-extra/clangd/TidyProvider.cpp | ||
307 | Callers here == diagnostics for config files that name unknown checks.
Yeah, ASSERT_FALSE(isFastCheck("misc-const-completeness")) and a corresponding positive case has some value even if we have to trivially update it sometimes. I'm less sure about setting up a complicated end-to-end case that we'll have to rewrite/delete if the list changes. |
Add tests of isFast
Make isFast a tristate (fast/unknown/slow)
Make the config option a tristate filter (strict/loose/none)
Emit diagnostics when enabling a (maybe)slow check in config
thanks LG, i'd like to hear how we're planning to let downstream users customise the list of fast checks. otherwise they have to run with Loose at all times.
the easiest i can think of is, generating their own fastchecks.inc fragment and #include that in addition to clangd's default list. Any other ideas on this one?
clang-tools-extra/clangd/ConfigCompile.cpp | ||
---|---|---|
508 | nit: s/Speed/Latency (or Performance?) | |
clang-tools-extra/clangd/TidyProvider.cpp | ||
333 | nit: some c++17 magic if you want: if (auto It = Fast.find(Check); It != Fast.end()) return It->second; return llvm::None; | |
clang-tools-extra/clangd/tool/Check.cpp | ||
109 | i think print-warnings is probably better than check we're not really checking anything. | |
113 | update the comment (or maybe even drop it?) |
Very late, & by email since phab is down.
Going to land this based on "LG" comment & offline discussion, happy to do
followups if needed.
nit: s/Speed/Latency (or Performance?)