================
@@ -373,15 +377,33 @@ void BlockInCriticalSectionChecker::checkPostCall(const
CallEvent &Call,
CheckerContext &C) const {
if (isBlockingInCritSection(Call, C)) {
reportBlockInCritSection(Call, C);
- } else if (std::optional<MutexDescriptor> LockDesc =
- checkDescriptorMatch(Call, C, /*IsLock=*/true)) {
- handleLock(*LockDesc, Call, C);
- } else if (std::optional<MutexDescriptor> UnlockDesc =
- checkDescriptorMatch(Call, C, /*IsLock=*/false)) {
+ return;
+ }
+
+ if (std::optional<MutexDescriptor> LockDesc =
+ checkDescriptorMatch(Call, C, /*IsLock=*/true)) {
+ if (!std::holds_alternative<RAIIMutexDescriptor>(*LockDesc))
+ handleLock(*LockDesc, Call, C);
+ return;
+ }
+ if (std::optional<MutexDescriptor> UnlockDesc =
+ checkDescriptorMatch(Call, C, /*IsLock=*/false)) {
handleUnlock(*UnlockDesc, Call, C);
}
}
+bool BlockInCriticalSectionChecker::evalCall(const CallEvent &Call,
+ CheckerContext &C) const {
+ if (std::optional<MutexDescriptor> LockDesc =
+ checkDescriptorMatch(Call, C, /*IsLock=*/true)) {
+ if (std::holds_alternative<RAIIMutexDescriptor>(*LockDesc)) {
----------------
steakhal wrote:
I think this is a fair concern. Give that these ctors dtors were inlined,
chances are that member functions would be inlined as well.
`scoped_lock` and `lock_guard` are fine. They don't have any operations and
non-copyables anyway.
The only case where it's concerning is `unique_lock`. It has some member
functions so I think the safe thing to do is to escape first, and then apply
the side effect. Good catch. Planning changes.
https://github.com/llvm/llvm-project/pull/208729
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
