kadircet added inline comments.

================
Comment at: clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp:280
 
+#if CLANGD_TIDY_CHECKS
 TEST_F(ConfigCompileTests, Tidy) {
----------------
why do we need to disable this test? it doesn't really build an ast or assert 
on the diagnostics from clang-tidy in any way, seems to be purely about configs.


================
Comment at: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp:151
   auto TU = TestTU::withCode(Test.code());
   TU.ClangTidyProvider = addTidyChecks("google-explicit-constructor");
   EXPECT_THAT(
----------------
you probably want to drop this too ?


================
Comment at: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp:167
-                            "change 'fod' to 'foo'"))),
-          // We make sure here that the entire token is highlighted
-          AllOf(Diag(Test.range("constructor"),
----------------
ah, this was actually checking for a particular change in the way we transform 
clang(-tidy) provided diag ranges to editor-friendly ones.

any diagnostic without any range info and containing a fix which is only 
insertion should be fine (one that i could find is `for_range_dereference`).


================
Comment at: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp:259
 
+    class T{$explicit[[]]$constructor[[T]](int a);};
+
----------------
ah, should've kept reading before leaving the comment above. feel free to 
ignore that (or just drop this test and rely only on clang diagnostics for 
checking that behaviour?)


================
Comment at: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp:301
+                                  "macro 'SQUARE' defined here"))),
               Diag(Test.range("macroarg"),
+                   "multiple unsequenced modifications to 'y'"),
----------------
i think we should suppress this with `-Wno-unsequenced` (and get rid of the 
`Else` part). Moreover this is the only test requiring an Else bit (if I didn't 
miss any). WDYT about just having a new file `TidyIntegrationTests` or 
`TidyDiagnosticTests` and moving all of these there, or having two different 
sections in this file to only enable these tests when tidy is on. It would 
imply tests that want to check a mix of tidy and clang diagnostics needs to go 
into the tidy section and cannot be tested on non-tidy builds, but that sounds 
like the price we need to pay anyway, whereas introducing the `ifTidyChecks` 
complicates things a little more (IMO).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105679/new/

https://reviews.llvm.org/D105679

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to