[PATCH] D87066: Thread safety analysis: Improve documentation for scoped capabilities

[Aaron Puchert via Phabricator via cfe-commits]

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