summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface
diff options
context:
space:
mode:
authorDonĂ¡t Nagy <donat.nagy@ericsson.com>2024-08-02 12:43:06 +0200
committerGitHub <noreply@github.com>2024-08-02 12:43:06 +0200
commit99ae2edc2592e602b0eb5a287f4d003aa3902440 (patch)
tree7edbf80c936ec278bf46aa34236eb812fc18a897 /lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface
parent92fbc963a51683d32f70d0c7f3783bb13983f08d (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/Interfaces/ScriptedProcessPythonInterface')
0 files changed, 0 insertions, 0 deletions