Thread safety analysis: Don't warn about managed locks on join points
authorAaron Puchert <aaron.puchert@sap.com>
Tue, 6 Apr 2021 20:29:44 +0000 (22:29 +0200)
committerAaron Puchert <aaron.puchert@sap.com>
Tue, 6 Apr 2021 20:29:48 +0000 (22:29 +0200)
commitdfec26b186d2f0c80f2b70901b7cc5747f5b377c
tree462f5a3e29e11f40528079e035518c3788c7c1ab
parent4bf8985f4fb1411831505a4b38265eb517783dc7
Thread safety analysis: Don't warn about managed locks on join points

We already did so for scoped locks acquired in the constructor, this
change extends the treatment to deferred locks and scoped unlocking, so
locks acquired outside of the constructor. Obviously this makes things
more consistent.

Originally I thought this was a bad idea, because obviously it
introduces false negatives when it comes to double locking, but these
are typically easily found in tests, and the primary goal of the Thread
safety analysis is not to find double locks but race conditions.
Since the scoped lock will release the mutex anyway when the scope ends,
the inconsistent state is just temporary and probably fine.

Reviewed By: delesley

Differential Revision: https://reviews.llvm.org/D98747
clang/lib/Analysis/ThreadSafety.cpp
clang/test/SemaCXX/warn-thread-safety-analysis.cpp