[all-commits] [llvm/llvm-project] 18ad02: [analyzer] Restore recognition of mutex methods (#...

[Donát Nagy via All-commits]

  Branch: refs/heads/release/19.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 18ad0209550ed258fc1a24e710613bc5e3e220af
      https://github.com/llvm/llvm-project/commit/18ad0209550ed258fc1a24e710613bc5e3e220af
  Author: Donát Nagy <donat.nagy at ericsson.com>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M clang/lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp
    A clang/test/Analysis/block-in-critical-section-inheritance.cpp

  Log Message:
  -----------
  [analyzer] Restore recognition of mutex methods (#101511)

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.

(cherry picked from commit 99ae2edc2592e602b0eb5a287f4d003aa3902440)



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications