diff options
| author | DonĂ¡t Nagy <donat.nagy@ericsson.com> | 2024-08-02 12:43:06 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-08-02 12:43:06 +0200 |
| commit | 99ae2edc2592e602b0eb5a287f4d003aa3902440 (patch) | |
| tree | 7edbf80c936ec278bf46aa34236eb812fc18a897 /lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp | |
| parent | 92fbc963a51683d32f70d0c7f3783bb13983f08d (diff) | |
[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.
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp')
0 files changed, 0 insertions, 0 deletions
