@llvm/pr-subscribers-clang-tidy

@llvm/pr-subscribers-clang-tools-extra

Author: Baranov Victor (vbvictor)

diff --git a/clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp b/clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
index bef3b938b5afd..ed9b195f0dbde 100644
--- a/clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ b/clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -102,8 +102,7 @@ Configuration files:
 )");
 
 const char DefaultChecks[] = // Enable these checks by default:
-    "clang-diagnostic-*,"    //   * compiler diagnostics
-    "clang-analyzer-*";      //   * Static Analyzer checks
+    "clang-diagnostic-*";    //   * compiler diagnostics
 
 static cl::opt<std::string> Checks("checks", desc(R"(
 Comma-separated list of globs with optional '-'
diff --git a/clang-tools-extra/docs/ReleaseNotes.rst b/clang-tools-extra/docs/ReleaseNotes.rst
index e1b6daf75457d..d97efe667f98e 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -139,6 +139,8 @@ Improvements to clang-tidy
   scripts by adding the `-hide-progress` option to suppress progress and
   informational messages.
 
+- Removed `clang-analyzer-*` check from default checks in :program:`clang-tidy`.
+
 New checks
 ^^^^^^^^^^
 

Perhaps having a section for "Breaking changes" or otherwise "Stuff you need to take action on" would help.

I support this, another solution could be bold text or preamble like "Important ⚠️".
But I think dedicated section is the best.

Perhaps having a section for "Breaking changes" or otherwise "Stuff you need to take action on" would help.

Filed #158434, once it is merged we could mark it as a breaking change.

✅ With the latest revision this PR passed the C/C++ code formatter.

Now that #158434 is merged, should we move the change to the release notes to that section?

Now that #158434 is merged, should we move the change to the release notes to that section?

Yes, I finally rebased on main and added new section

But do we want to mention the change twice in the change log? In another PR we are only mentioning the breaking change in the breaking changes section, not again in the improvement's section.

But do we want to mention the change twice in the change log? In another PR we are only mentioning the breaking change in the breaking changes section, not again in the improvement's section.

I initially thought to duplicate entries just in case if someone would read only clang-tidy part. I think it's better to have in both

I totally agree with the consistency. I personally think once is fine, but twice won't hurt.

The other PR I mentioned would be #161064

I totally agree with the consistency. I personally think once is fine, but twice won't hurt.

The other PR I mentioned would be #161064

Oh, must have missed that, we probably should add in tidy release notes for consistency