================ @@ -0,0 +1,11 @@ +// REQUIRES: clangd-tidy-checks +// RUN: cp %s %t.cpp +// RUN: clangd -enable-config=0 -clang-tidy=0 -check=%t.cpp -check-tidy-time=-* 2>&1 | FileCheck %s + +// Time only baseline builds to avoid timing-stability retries. +// CHECK: Timing AST build with individual clang-tidy checks +// CHECK: Baseline = +// CHECK: Finished individual clang-tidy checks +// CHECK: All checks completed, 0 errors ---------------- ArcsinX wrote:
> Hm, let me ask you a different question, you said you actually ran into this > regression, so you had a reason to use this combination? Because then this > might actually be more favourable in keeping the behaviour. I mean as you > said it is rather easy to keep so why not. To ensure that moving clang-tidy functionality into a feature module won't lead to any regressions from user standpoint, I just played with `clang-tidy`-related clangd command line options and config, and compare behavior (current clangd vs clangd where clang-tidy functionality is moved into feature module). And found this difference in behavior. So, there was no real usage scenario from my side. > The only question we could think about is if we want to guarantee this > behaviour by adding a test. If we don't, worst case, it breaks eventually and > we get a bug report down the line and then can decide on if we want this > behaviour or not. This also means we do not really guarantee the behaviour > (because I guess having a test can be seen as this), so a removal later on > might run us less trouble with users. Overall though I think this is a minor > thing and we can just do whatever. Agree, now I lean towards removing this test, because guarantee such behavior looks a bit strange. https://github.com/llvm/llvm-project/pull/231461 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
