[all-commits] [llvm/llvm-project] 530e07: Thread safety analysis: Replace flags in FactEntry...

[Aaron Puchert via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 530e074faafe995a560e80815f5af8306670ea7b
      https://github.com/llvm/llvm-project/commit/530e074faafe995a560e80815f5af8306670ea7b
  Author: Aaron Puchert <aaron.puchert at sap.com>
  Date:   2021-05-03 (Mon, 03 May 2021)

  Changed paths:
    M clang/lib/Analysis/ThreadSafety.cpp

  Log Message:
  -----------
  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


  Commit: daca6edb31efae048a420595fae9750aaa91c733
      https://github.com/llvm/llvm-project/commit/daca6edb31efae048a420595fae9750aaa91c733
  Author: Aaron Puchert <aaron.puchert at sap.com>
  Date:   2021-05-03 (Mon, 03 May 2021)

  Changed paths:
    M clang/lib/Analysis/ThreadSafety.cpp
    M clang/test/PCH/thread-safety-attrs.cpp
    M clang/test/SemaCXX/warn-thread-safety-analysis.cpp

  Log Message:
  -----------
  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


Compare: https://github.com/llvm/llvm-project/compare/876bf516e7d4...daca6edb31ef