This patch allows building a clang binary that has clang-tidy checks embedded into the static analyzer. I discussed these plans briefly in https://lists.llvm.org/pipermail/cfe-dev/2020-October/067002.html.
WIP because i haven't handled any build-time settings yet. This new facility will be under a CMake flag and most likely off by default (unless everybody suddenly loves this option, but even then, I still have to turn it into an option). I'll make sure to implement (and hopefully test) a reasonable behavior for all various combinations of CMake flags (eg., clang-tidy enabled/disabled, static analyzer enabled/disabled, static-analyzer-into-clang-tidy integration enabled/disabled, etc.).
This patch introduces a frontend flag -analyzer-tidy-checker=... that accepts clang-tidy checker strings (eg., -analyzer-tidy-checker=bugprone-*,-cert-*,cert-env33-c). As long as at least one such flag is supplied, ClangTidyContext is instantiated with the given checker list and a clang-tidy AST consumer gets multiplexed with AnalysisConsumer so that to run clang-tidy checkers. Diagnostics from these checks are pumped into a PathDiagnosticConverterDiagnosticConsumer (D94476) and displayed similarly to static analyzer diagnostics, eg. as HTML or Plist reports:
This patch suggests enabling a few clang-tidy checks by default in Clang Driver (under the --analyze flag, obviously, and the new reverse integration should be enabled first). Requirements for enabling a clang-tidy check by default would be similar to requirements of enabling a static analyzer check by default (finds real bugs by design, understandable diagnostics, etc.). Additionally, on-by-default clang-tidy checks should have static analyzer bug categories assigned to them (eg., "Logic error", "Memory error", etc.) in the diagnostic converter (a relatively convenient way to do so is provided).
If bug categories aren't assigned, the default bug category for clang-tidy check x-y-z is Clang-Tidy [x] and the default bug type is Clang-Tidy [x-y-z]. This looks pretty ok in scan-build's index.html:
That said, we should probably provide an option to disable bug category conversion and use it whenever an arbitrary clang-tidy config is expected. As usual, we're optimizing for a reasonable default rather than for configurability.
I've considered a different approach to enabling/disabling clang-tidy checks (but didn't implement it in this patch) that's more static analyzer-like: -analyzer-checker tidy.bugprone.assert-side-effect etc. Here we treat x in x-y-z as a static analyzer package, hence the dot. This approach is less flexible because it doesn't allow arbitrary wildcards, so we still have to have the current approach but we should probably implement both. One thing to think about here would be to figure out whether each individual off-by-default clang-tidy check is treated as "alpha" ("we're not supporting it, don't use it") or opt-in ("we're supporting it but it's still of by default"). Probably we could additionally separate them into alpha.tidy.* and optin.tidy.*.
Clang-tidy check-specific options are not implemented yet. Again, we could provide a separate frontend flag, or we could interface them through AnalyzerOptions like this: -analyzer-config tidy.bugprone.assert-side-effect:AssertMacros=assert,Assert,ASSERT. And, again, we should probably do both.
Can you please use the option marshalling infrastructure instead? https://clang.llvm.org/docs/InternalsManual.html#adding-new-command-line-option