[PATCH] D87629: Thread safety analysis: Improve documentation for ASSERT_CAPABILITY
Vasil Dimov via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Sep 15 01:45:27 PDT 2020
vasild added inline comments.
================
Comment at: clang/docs/ThreadSafetyAnalysis.rst:452-454
+and terminating or throwing if the capability is not held. Presence of this
+annotation causes the analysis to assume the capability is held at the point of
+the call. See :ref:`mutexheader`, below, for example uses.
----------------
aaronpuchert wrote:
> That's an interesting point. We currently do assume that the capability is held even when an exception is thrown, although that's primarily because Clang's source-level CFG doesn't really model exception handling that well:
>
> ```
> Mutex mu;
> bool a GUARDED_BY(mu);
>
> void except() {
> try {
> mu.AssertHeld();
> } catch (...) {
> a = 0; // No warning.
> }
> }
> ```
>
> We can't warn there because `AssertHeld` might terminate in case the mutex isn't held.
>
> Not sure if we need to clarify this here: we just assume that the capability is held on a regular return. The other case is basically UB for us.
Maybe don't mention "throwing", given the example above and `s/at the call/after the call/`.
It is similar to:
```
void f(char x, unsigned char y)
{
assert(x >= 0);
assert(y <= 127);
if (x > y) { // it is ok to omit a warning about comparing signed and unsigned because AFTER the asserts we know we are good.
...
}
}
```
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D87629/new/
https://reviews.llvm.org/D87629
More information about the cfe-commits
mailing list