-
Notifications
You must be signed in to change notification settings - Fork 14.7k
Thread safety analysis: Don't warn on acquiring reentrant capability #150857
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thread safety analysis: Don't warn on acquiring reentrant capability #150857
Conversation
The point of reentrant capabilities is that they can be acquired multiple times, so they should probably be excluded from requiring a negative capability on acquisition via -Wthread-safety-negative. However, we still propagate explicit negative requirements.
@llvm/pr-subscribers-clang @llvm/pr-subscribers-clang-analysis Author: Aaron Puchert (aaronpuchert) ChangesThe point of reentrant capabilities is that they can be acquired multiple times, so they should probably be excluded from requiring a negative capability on acquisition via -Wthread-safety-negative. However, we still propagate explicit negative requirements. Full diff: https://github.com/llvm/llvm-project/pull/150857.diff 2 Files Affected:
diff --git a/clang/lib/Analysis/ThreadSafety.cpp b/clang/lib/Analysis/ThreadSafety.cpp
index 80e7c8eff671a..dadb0b757a2c8 100644
--- a/clang/lib/Analysis/ThreadSafety.cpp
+++ b/clang/lib/Analysis/ThreadSafety.cpp
@@ -1331,7 +1331,7 @@ void ThreadSafetyAnalyzer::addLock(FactSet &FSet,
FSet.removeLock(FactMan, NegC);
}
else {
- if (inCurrentScope(*Entry) && !Entry->asserted())
+ if (inCurrentScope(*Entry) && !Entry->asserted() && !Entry->reentrant())
Handler.handleNegativeNotHeld(Entry->getKind(), Entry->toString(),
NegC.toString(), Entry->loc());
}
diff --git a/clang/test/SemaCXX/warn-thread-safety-negative.cpp b/clang/test/SemaCXX/warn-thread-safety-negative.cpp
index 9eabd67e4fc76..0caf6d6139e58 100644
--- a/clang/test/SemaCXX/warn-thread-safety-negative.cpp
+++ b/clang/test/SemaCXX/warn-thread-safety-negative.cpp
@@ -21,6 +21,15 @@ class LOCKABLE Mutex {
void AssertReaderHeld() ASSERT_SHARED_LOCK();
};
+class LOCKABLE REENTRANT_CAPABILITY ReentrantMutex {
+public:
+ void Lock() EXCLUSIVE_LOCK_FUNCTION();
+ void Unlock() UNLOCK_FUNCTION();
+
+ // for negative capabilities
+ const ReentrantMutex& operator!() const { return *this; }
+};
+
class SCOPED_LOCKABLE MutexLock {
public:
MutexLock(Mutex *mu) EXCLUSIVE_LOCK_FUNCTION(mu);
@@ -89,6 +98,29 @@ class Foo {
}
};
+class Reentrant {
+ ReentrantMutex mu;
+
+public:
+ void acquire() {
+ mu.Lock(); // no warning -- reentrant mutex
+ mu.Unlock();
+ }
+
+ void requireNegative() EXCLUSIVE_LOCKS_REQUIRED(!mu) { // warning?
+ mu.Lock();
+ mu.Unlock();
+ }
+
+ void callRequireNegative() {
+ requireNegative(); // expected-warning{{calling function 'requireNegative' requires negative capability '!mu'}}
+ }
+
+ void callHaveNegative() EXCLUSIVE_LOCKS_REQUIRED(!mu) {
+ requireNegative();
+ }
+};
+
} // end namespace SimpleTest
Mutex globalMutex;
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/123/builds/24610 Here is the relevant piece of the build log for the reference
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/186/builds/11280 Here is the relevant piece of the build log for the reference
|
/cherry-pick a048aeb |
/pull-request #151889 |
…lvm#150857) The point of reentrant capabilities is that they can be acquired multiple times, so they should probably be excluded from requiring a negative capability on acquisition via -Wthread-safety-negative. However, we still propagate explicit negative requirements. (cherry picked from commit a048aeb)
The point of reentrant capabilities is that they can be acquired multiple times, so they should probably be excluded from requiring a negative capability on acquisition via -Wthread-safety-negative.
However, we still propagate explicit negative requirements.