Thread safety analysis: Support builtin pointer-to-member operators

We consider an access to x.*pm as access of the same kind into x, and
an access to px->*pm as access of the same kind into *px. Pr

Thread safety analysis: Support builtin pointer-to-member operators

We consider an access to x.*pm as access of the same kind into x, and
an access to px->*pm as access of the same kind into *px. Previously we
missed reads and writes in the .* case, and operations to the pointed-to
data for ->* (we didn't miss accesses to the pointer itself, because
that requires an LValueToRValue cast that we treat independently).

We added support for overloaded operator->* in D124966.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D129514

show more ...

Thread safety analysis: Handle compound assignment and ->* overloads

Like regular assignment, compound assignment operators can be assumed to
write to their left-hand side operand. So we strengthen

Thread safety analysis: Handle compound assignment and ->* overloads

Like regular assignment, compound assignment operators can be assumed to
write to their left-hand side operand. So we strengthen the requirements
there. (Previously only the default read access had been required.)

Just like operator->, operator->* can also be assumed to dereference the
left-hand side argument, so we require read access to the pointee. This
will generate new warnings if the left-hand side has a pt_guarded_by
attribute. This overload is rarely used, but it was trivial to add, so
why not. (Supporting the builtin operator requires changes to the TIL.)

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D124966

show more ...

Thread safety analysis: Don't pass capability kind where not needed (NFC)

If no capability is held, or the capability expression is invalid, there
is obviously no capability kind and so none would b

Thread safety analysis: Don't pass capability kind where not needed (NFC)

If no capability is held, or the capability expression is invalid, there
is obviously no capability kind and so none would be reported.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D124132

show more ...

Thread safety analysis: Store capability kind in CapabilityExpr

This should make us print the right capability kind in many more cases,
especially when attributes name multiple capabilities of diffe

Thread safety analysis: Store capability kind in CapabilityExpr

This should make us print the right capability kind in many more cases,
especially when attributes name multiple capabilities of different kinds.

Previously we were trying to deduce the capability kind from the
original attribute, but most attributes can name multiple capabilities,
which could be of different kinds. So instead we derive the kind when
translating the attribute expression, and then store it in the returned
CapabilityExpr. Then we can extract the corresponding capability name
when we need it, which saves us lots of plumbing and almost guarantees
that the name is right.

I didn't bother adding any tests for this because it's just a usability
improvement and it's pretty much evident from the code that we don't
fall back to "mutex" anymore (save for a few cases that I'll address in
a separate change).

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D124131

show more ...

Thread safety analysis: Store CapabilityExprs in ScopedLockableFactEntry (NFC)

For now this doesn't make a whole lot of sense, but it will allow us to
store the capability kind in a CapabilityExpr a

Thread safety analysis: Store CapabilityExprs in ScopedLockableFactEntry (NFC)

For now this doesn't make a whole lot of sense, but it will allow us to
store the capability kind in a CapabilityExpr and make sure it doesn't
get lost. The capabilities managed by a scoped lockable can of course be
of different kind, so we'll need to store that per entry.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D124128

show more ...

Thread safety analysis: Remove unused variable. NFC.

Use llvm::any_of and llvm::none_of (NFC)

Thread safety analysis: Drop special block handling

Previous changes like D101202 and D104261 have eliminated the special
status that break and continue once had, since now we're making
decisions pu

Thread safety analysis: Drop special block handling

Previous changes like D101202 and D104261 have eliminated the special
status that break and continue once had, since now we're making
decisions purely based on the structure of the CFG without regard for
the underlying source code constructs.

This means we don't gain anything from defering handling for these
blocks. Dropping it moves some diagnostics, though arguably into a
better place. We're working around a "quirk" in the CFG that perhaps
wasn't visible before: while loops have an empty "transition block"
where continue statements and the regular loop exit meet, before
continuing to the loop entry. To get a source location for that, we
slightly extend our handling for empty blocks. The source location for
the transition ends up to be the loop entry then, but formally this
isn't a back edge. We pretend it is anyway. (This is safe: we can always
treat edges as back edges, it just means we allow less and don't modify
the lock set. The other way around it wouldn't be safe.)

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D106715

show more ...

Thread safety analysis: Warn when demoting locks on back edges

Previously in D104261 we warned about dropping locks from back edges,
this is the corresponding change for exclusive/shared joins. If w

Thread safety analysis: Warn when demoting locks on back edges

Previously in D104261 we warned about dropping locks from back edges,
this is the corresponding change for exclusive/shared joins. If we're
entering the loop with an exclusive change, which is then relaxed to a
shared lock before we loop back, we have already analyzed the loop body
with the stronger exclusive lock and thus might have false positives.

There is a minor non-observable change: we modify the exit lock set of a
function, but since that isn't used further it doesn't change anything.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D106713

show more ...

Thread safety analysis: Rename parameters of ThreadSafetyAnalyzer::intersectAndWarn (NFC)

In D104261 we made the parameters' meaning slightly more specific, this
changes their names accordingly. In

Thread safety analysis: Rename parameters of ThreadSafetyAnalyzer::intersectAndWarn (NFC)

In D104261 we made the parameters' meaning slightly more specific, this
changes their names accordingly. In all uses we're building a new lock
set by intersecting existing locksets. The first (modifiable) argument
is the new lock set being built, the second (non-modifiable) argument is
the exit set of a preceding block.

Reviewed By: aaron.ballman, delesley

Differential Revision: https://reviews.llvm.org/D104649

show more ...

Thread safety analysis: Always warn when dropping locks on back edges

We allow branches to join where one holds a managed lock but the other
doesn't, but we can't do so for back edges: because there

Thread safety analysis: Always warn when dropping locks on back edges

We allow branches to join where one holds a managed lock but the other
doesn't, but we can't do so for back edges: because there we can't drop
them from the lockset, as we have already analyzed the loop with the
larger lockset. So we can't allow dropping managed locks on back edges.

We move the managed() check from handleRemovalFromIntersection up to
intersectAndWarn, where we additionally check if we're on a back edge if
we're removing from the first lock set (the entry set of the next block)
but not if we're removing from the second lock set (the exit set of the
previous block). Now that the order of arguments matters, I had to swap
them in one invocation, which also causes some minor differences in the
tests.

Reviewed By: delesley

Differential Revision: https://reviews.llvm.org/D104261

show more ...

[clang] NFC: Rename rvalue to prvalue

This renames the expression value categories from rvalue to prvalue,
keeping nomenclature consistent with C++11 onwards.

C++ has the most complicated taxonomy

[clang] NFC: Rename rvalue to prvalue

This renames the expression value categories from rvalue to prvalue,
keeping nomenclature consistent with C++11 onwards.

C++ has the most complicated taxonomy here, and every other language
only uses a subset of it, so it's less confusing to use the C++ names
consistently, and mentally remap to the C names when working on that
context (prvalue -> rvalue, no xvalues, etc).

Renames:
* VK_RValue -> VK_PRValue
* Expr::isRValue -> Expr::isPRValue
* SK_QualificationConversionRValue -> SK_QualificationConversionPRValue
* JSON AST Dumper Expression nodes value category: "rvalue" -> "prvalue"

Signed-off-by: Matheus Izvekov <[email protected]>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D103720

show more ...

Thread safety analysis: Allow exlusive/shared joins for managed and asserted capabilities

Similar to how we allow managed and asserted locks to be held and not
held in joining branches, we also allo

Thread safety analysis: Allow exlusive/shared joins for managed and asserted capabilities

Similar to how we allow managed and asserted locks to be held and not
held in joining branches, we also allow them to be held shared and
exclusive. The scoped lock should restore the original state at the end
of the scope in any event, and asserted locks need not be released.

We should probably only allow asserted locks to be subsumed by managed,
not by (directly) acquired locks, but that's for another change.

Reviewed By: delesley

Differential Revision: https://reviews.llvm.org/D102026

show more ...

Thread safety analysis: Factor out function for merging locks (NFC)

It's going to become a bit more complicated, so let's have it separate.

Reviewed By: aaron.ballman

Differential Revision: https:

Thread safety analysis: Factor out function for merging locks (NFC)

It's going to become a bit more complicated, so let's have it separate.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D102025

show more ...

Thread safety analysis: Eliminate parameter from intersectAndWarn (NFC)

We were modifying precisely when intersecting the lock sets of multiple
predecessors without back edge. That's no coincidence:

Thread safety analysis: Eliminate parameter from intersectAndWarn (NFC)

We were modifying precisely when intersecting the lock sets of multiple
predecessors without back edge. That's no coincidence: we can't modify
on back edges, it doesn't make sense to modify at the end of a function,
and otherwise we always want to intersect on forward edges, because we
can build a new lock set for those.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D101755

show more ...

Thread safety analysis: Fix false negative on break

We weren't modifying the lock set when intersecting with one coming
from a break-terminated block. This is inconsistent, since break isn't a
back

Thread safety analysis: Fix false negative on break

We weren't modifying the lock set when intersecting with one coming
from a break-terminated block. This is inconsistent, since break isn't a
back edge, and it leads to false negatives with scoped locks. We usually
don't warn for those when joining locksets aren't the same, we just
silently remove locks that are not in the intersection. But not warning
and not removing them isn't right.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D101202

show more ...

Thread safety analysis: Replace flags in FactEntry by SourceKind (NFC)

The motivation here is to make it available in the base class whether a
fact is managed or not. That would have meant three fla

Thread safety analysis: Replace flags in FactEntry by SourceKind (NFC)

The motivation here is to make it available in the base class whether a
fact is managed or not. That would have meant three flags on the base
class, so I had a look whether we really have 8 possible combinations.

It turns out we don't: asserted and declared are obviously mutually
exclusive. Managed facts are only created when we acquire a capability
through a scoped capability. Adopting an asserted or declared lock will
not (in fact can not, because Facts are immutable) make them managed.

We probably don't want to allow adopting an asserted lock (because then
the function should probably have a release attribute, and then the
assertion is pointless), but we might at some point decide to replace a
declared fact on adoption.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D100801

show more ...

Thread safety analysis: Simplify intersectAndWarn (NFC)

Instead of conditionally overwriting a nullptr and then branching on its
nullness, just branch directly on the original condition. Then we can

Thread safety analysis: Simplify intersectAndWarn (NFC)

Instead of conditionally overwriting a nullptr and then branching on its
nullness, just branch directly on the original condition. Then we can
make both pointers (non-null) references instead.

show more ...

Thread safety analysis: Don't warn about managed locks on join points

We already did so for scoped locks acquired in the constructor, this
change extends the treatment to deferred locks and scoped u

Thread safety analysis: Don't warn about managed locks on join points

We already did so for scoped locks acquired in the constructor, this
change extends the treatment to deferred locks and scoped unlocking, so
locks acquired outside of the constructor. Obviously this makes things
more consistent.

Originally I thought this was a bad idea, because obviously it
introduces false negatives when it comes to double locking, but these
are typically easily found in tests, and the primary goal of the Thread
safety analysis is not to find double locks but race conditions.
Since the scoped lock will release the mutex anyway when the scope ends,
the inconsistent state is just temporary and probably fine.

Reviewed By: delesley

Differential Revision: https://reviews.llvm.org/D98747

show more ...

Deduplicate branches and adjust comment [NFC]

Currently we want to allow calling non-const methods even when only a
shared lock is held, because -Wthread-safety-reference is already quite
sensitive

Deduplicate branches and adjust comment [NFC]

Currently we want to allow calling non-const methods even when only a
shared lock is held, because -Wthread-safety-reference is already quite
sensitive and not all code is const-correct. Even if it is, this might
require users to add std::as_const around the implicit object argument.

See D52395 for a discussion.

Fixes PR46963.

show more ...

Thread safety analysis: Consider static class members as inaccessible

This fixes the issue pointed out in D84604#2363134. For now we exclude
static members completely, we'll take them into account l

Thread safety analysis: Consider static class members as inaccessible

This fixes the issue pointed out in D84604#2363134. For now we exclude
static members completely, we'll take them into account later.

show more ...

Thread safety analysis: Nullability improvements in TIL, NFCI

The constructor of Project asserts that the contained ValueDecl is not
null, use that in the ThreadSafetyAnalyzer. In the case of Litera

Thread safety analysis: Nullability improvements in TIL, NFCI

The constructor of Project asserts that the contained ValueDecl is not
null, use that in the ThreadSafetyAnalyzer. In the case of LiteralPtr
it's the other way around.

Also dyn_cast<> is sufficient if we know something isn't null.

show more ...

Thread safety analysis: Consider global variables in scope

Instead of just mutex members we also consider mutex globals.
Unsurprisingly they are always in scope. Now the paper [1] says that

> The s

Thread safety analysis: Consider global variables in scope

Instead of just mutex members we also consider mutex globals.
Unsurprisingly they are always in scope. Now the paper [1] says that

> The scope of a class member is assumed to be its enclosing class,
> while the scope of a global variable is the translation unit in
> which it is defined.

But I don't think we should limit this to TUs where a definition is
available - a declaration is enough to acquire the mutex, and if a mutex
is really limited in scope to a translation unit, it should probably be
only declared there.

The previous attempt in 9dcc82f34ea was causing false positives because
I wrongly assumed that LiteralPtrs were always globals, which they are
not. This should be fixed now.

[1] https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42958.pdf

Fixes PR46354.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D84604

show more ...

Temporairly revert "Thread safety analysis: Consider global variables in scope" & followup

This appears to cause false-positives because it started to warn on local non-global variables.

Repro post

Temporairly revert "Thread safety analysis: Consider global variables in scope" & followup

This appears to cause false-positives because it started to warn on local non-global variables.

Repro posted to https://reviews.llvm.org/D84604#2262745

This reverts commit 9dcc82f34ea9b623d82d2577b93aaf67d36dabd2.
This reverts commit b2ce79ef66157dd752e3864ece57915e23a73f5d.

show more ...

Thread safety analysis: ValueDecl in Project is non-null

The constructor asserts that, use it in the ThreadSafetyAnalyzer.
Also note that the result of a cast<> cannot be null.