[analyzer] Restore recognition of mutex methods

[NagyDonat]

Before commit 705788c the checker alpha.unix.BlockInCriticalSection "recognized" the methods std::mutex::lock and std::mutex::unlock with an extremely trivial check that accepted any function (or method) named lock/unlock.

To avoid matching unrelated user-defined function, this was refined to a check that also requires the presence of "std" and "mutex" as distinct parts of the qualified name.

However, as #99628 reported, there are standard library implementations where some methods of std::mutex are inherited from an implementation detail base class and the new code wasn't able to recognize these methods, which led to emitting false positive reports.

As a workaround, this commit partially restores the old behavior by omitting the check for the class name.

In the future, it would be good to replace this hack with a solution which ensures that CallDescription understands inherited methods.

[llvmbot]

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-static-analyzer-1

Author: Donát Nagy (NagyDonat)

Changes

Before commit 705788c the checker alpha.unix.BlockInCriticalSection "recognized" the methods std::mutex::lock and std::mutex::unlock with an extremely trivial check that accepted any function (or method) named lock/unlock.

To avoid matching unrelated user-defined function, this was refined to a check that also requires the presence of "std" and "mutex" as distinct parts of the qualified name.

However, as #99628 reported, there are standard library implementations where some methods of std::mutex are inherited from an implementation detail base class and the new code wasn't able to recognize these methods, which led to emitting false positive reports.

As a workaround, this commit partially restores the old behavior by omitting the check for the class name.

In the future, it would be good to replace this hack with a solution which ensures that CallDescription understands inherited methods.

---

Full diff: https://github.com/llvm/llvm-project/pull/101511.diff

1 Files Affected:

• (modified) clang/lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp (+12-4)

diff --git a/clang/lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp b/clang/lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp
index 40f7e9cede1f1..4cd2f2802f30c 100644
--- a/clang/lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp
@@ -147,10 +147,18 @@ using MutexDescriptor =
 class BlockInCriticalSectionChecker : public Checker<check::PostCall> {
 private:
   const std::array<MutexDescriptor, 8> MutexDescriptors{
-      MemberMutexDescriptor({/*MatchAs=*/CDM::CXXMethod,
-                             /*QualifiedName=*/{"std", "mutex", "lock"},
-                             /*RequiredArgs=*/0},
-                            {CDM::CXXMethod, {"std", "mutex", "unlock"}, 0}),
+      // NOTE: There are standard library implementations where some methods
+      // of `std::mutex` are inherited from an implementation detail base
+      // class, and those aren't matched by the name specification {"std",
+      // "mutex", "lock"}.
+      // As a workaround here we omit the class name and only require the
+      // presence of the name parts "std" and "lock"/"unlock".
+      // TODO: Ensure that CallDescription understands inherited methods.
+      MemberMutexDescriptor(
+          {/*MatchAs=*/CDM::CXXMethod,
+           /*QualifiedName=*/{"std", /*"mutex",*/ "lock"},
+           /*RequiredArgs=*/0},
+          {CDM::CXXMethod, {"std", /*"mutex",*/ "unlock"}, 0}),
       FirstArgMutexDescriptor({CDM::CLibrary, {"pthread_mutex_lock"}, 1},
                               {CDM::CLibrary, {"pthread_mutex_unlock"}, 1}),
       FirstArgMutexDescriptor({CDM::CLibrary, {"mtx_lock"}, 1},

[steakhal]

LGTM.
Could you add a test case that would break in case we would regress?

[steakhal]

Let's merge this, and backport it into clang-19. I'll deal with that.

[NagyDonat]

Let's merge this, and backport it into clang-19. I'll deal with that.

Thanks!

[steakhal]

Backport PR in #101651