https://github.com/aaronpuchert commented:
> Previously, when the result of a try-lock call is branched on more than once, > the paths between the branches would disagree on whether the capability is > held while remaining consistent at each branch. The analysis then gave a > false positive warning at the intermediate join: This behavior is [documented](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#try-acquire-bool-try-acquire-shared-bool) though: > a capability is treated as acquired after the first branch on the return > value of a try-acquire function. So this limitation is intentional, and I don't really understand why we should lift it. Once you've branched you have the lock in one branch and not in the other. When they join without further operations in either branch, we have two branches with different lock sets join. Accepting this because there is another branch immediately after that seems like we're carving out a very special case, one that could easily be avoided by simply threading the jumps. I assume these are macro artifacts? In general I'm Ok with getting more code to work, but this behavior is documented and the solution is not very clean in my opinion. https://github.com/llvm/llvm-project/pull/209796 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
