aaronpuchert added inline comments.
================
Comment at: clang/docs/ThreadSafetyAnalysis.rst:908
+ // Assumes mu is held, implicitly acquires *this and connects it to mu.
+ MutexLocker(t_mutex &mu, adopt_lock_t) REQUIRES(mu) : mut(mu) {}
+
----------------
`s/t_mutex/Mutex/g`
================
Comment at: clang/docs/ThreadSafetyAnalysis.rst:922
+ // Releases *this and all underlying capabilities, if they are still held.
+ // There is no warning on double unlock.
~MutexLocker() RELEASE() {
----------------
aaron.ballman wrote:
> This makes it sound like we're missing a diagnostic, but IIRC, this is
> intended behavior. Maybe we want to say there is purposefully no warning on
> double unlock and why? Or add a FIXME if I'm remembering wrong and this isn't
> intended behavior.
It is intentional (we have special handling for the destructor), and I also
think it makes sense. I just wanted to clarify the difference between this and
`Unlock`: calling `Unlock` twice is not allowed, but calling `Unlock` and then
(implicitly) the destructor is allowed.
I could rephrase this as "There is no warning if the scope was already unlocked
before." Could also add an "intentional" or "deliberate", but since it's
documented I think the reader can infer that.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D87066/new/
https://reviews.llvm.org/D87066
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
