================
@@ -297,7 +300,16 @@ class Checker {
// step-function slowdowns due to CPU scaling.
// We take the median of 5 measurements, and after every check discard the
// measurement if the baseline changed by >3%.
- void checkTidyTimes() {
+ bool checkTidyTimes() {
+ // Keep all other modules active while varying only tidy's configuration.
+ auto *TidyModule =
+ Inputs.FeatureModules
+ ? Inputs.FeatureModules->get<ClangTidyFeatureModule>()
----------------
ArcsinX wrote:
>From feature module usage standpoint, this fits the original feature module
>design, which explicitly allows modules to expose a public API through typed
>lookup (some info can be found n [this
>comment](https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clangd/FeatureModule.h#L177))
> Does the module need an extra call, does data need to flow differently...?
Flow in this particular case is really a bit different. Previously clang-tidy
provider was a part of `ParseInputs`, so it was possible just to replace it
here. With this PR clang-tidy provider is a part of the clang-tidy feature
module, so we need to call public feature module API to replace (and restore)
clang-tidy provider.
As far as `checkTidyTimes()` is a clang-tidy specific function, I think it's ok
to call a public clang-tidy feature module API from it. Also, this code is not
a part of clangd core library, parsing and diagnostic infrastructure remains
independent of the concrete module.
https://github.com/llvm/llvm-project/pull/236054
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
