[PATCH] D83224: [clangd] Move clang-tidy check modifications into ClangdServer

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang-tools-extra/clangd/ClangdServer.cpp:120
+                       // clangd doesn't replay those when using a preamble.
+                       "-llvm-header-guard");
+  static const std::string CrashingChecks =
----------------
sammccall wrote:
> aaron.ballman wrote:
> > sammccall wrote:
> > > aaron.ballman wrote:
> > > > njames93 wrote:
> > > > > aaron.ballman wrote:
> > > > > > I suspect there are more checks that should be added here. For instance, much of `modernize-` is purely stylistic so it's easy to view as being false positives (like `modernize-use-trailing-return-types` or whatever it's called).
> > > > > I don't think that's what this list is for. This seems to be purely for checks that don't run properly or crash inside clangd. `modernize-use-trailing-return-types` is a very noisy check but that's how it is when ran as normal clang-tidy. 
> > > > Ah, thank you for the explanation. Then how about `UnusableWithinClangd` or something other than `FalsePositives` for the name?
> > > The whole list is of checks that aren't usable in clangd, FalsePositives is the specific reason. What's the problem with the name?
> > > What's the problem with the name?
> > 
> > If this is a list of checks that should be disabled because they have a ton of false positives, I think the name is fine and the list is incomplete. If this is a list of checks that should be disabled because they're not well-supported in clangd specifically, I think the name is misleading and the list is fine.
> > If this is a list of checks that should be disabled because they're not well-supported in clangd specifically, I think the name is misleading and the list is fine.
> 
> Fair enough - I think there's enough context to not need to repeat "in clangd" here though. This code is in clangd, in a function with a comment indicating that it's for checks that don't work well specifically in clangd. (Maybe s/not suitable to be run through clangd/don't work well in clangd/ though).
> Fair enough - I think there's enough context to not need to repeat "in clangd" here though. This code is in clangd, in a function with a comment indicating that it's for checks that don't work well specifically in clangd. (Maybe s/not suitable to be run through clangd/don't work well in clangd/ though).

That makes sense to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83224