This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Don't run slow clang-tidy checks by default
ClosedPublic

Authored by sammccall on Nov 22 2022, 8:33 AM.

Details

Summary

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.

Fixes https://github.com/clangd/clangd/issues/1337

Diff Detail

Event Timeline

sammccall created this revision.Nov 22 2022, 8:33 AM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: arphaman. · View Herald Transcript
sammccall requested review of this revision.Nov 22 2022, 8:33 AM

Ideas on testing welcome. Does it make sense to rely on the fact that misc-const-correctness is always slow? :-D

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?

sammccall added inline comments.Nov 23 2022, 2:57 AM
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.

sammccall planned changes to this revision.Nov 23 2022, 3:16 AM
sammccall added inline comments.
clang-tools-extra/clangd/ConfigCompile.cpp
558

This is a boolean, so there's an obvious+wrong interpretation of that version.
I think has_value, uh, has value here.

clang-tools-extra/clangd/TidyProvider.cpp
307

Callers here == diagnostics for config files that name unknown checks.
I can add a warning for naming a slow check too, that makes sense.

this might as well be our way of testing this to some extent

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.

sammccall retitled this revision from [clangd] Don't run slow clang-tidy checks to [clangd] Don't run slow clang-tidy checks by default.
sammccall edited the summary of this revision. (Show Details)

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.

This revision was not accepted when it landed; it landed in state Needs Review.Oct 20 2023, 2:48 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.