[all-commits] [llvm/llvm-project] dd1790: Thread safety analysis: Pack CapabilityExpr using ...

[Aaron Puchert via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: dd1790cd05ae124e9e5d57dfe9279ff54f34b488
      https://github.com/llvm/llvm-project/commit/dd1790cd05ae124e9e5d57dfe9279ff54f34b488
  Author: Aaron Puchert <aaron.puchert at sap.com>
  Date:   2022-04-29 (Fri, 29 Apr 2022)

  Changed paths:
    M clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h

  Log Message:
  -----------
  Thread safety analysis: Pack CapabilityExpr using PointerIntPair (NFC)

We're storing these quite frequently: FactEntry inherits from
CapabilityExpr, and the FactManager has a vector of such entries.

Reviewed By: aaron.ballman

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


  Commit: d65c922450d1fdf0f44f4a10a8f33b11c6c01bf5
      https://github.com/llvm/llvm-project/commit/d65c922450d1fdf0f44f4a10a8f33b11c6c01bf5
  Author: Aaron Puchert <aaron.puchert at sap.com>
  Date:   2022-04-29 (Fri, 29 Apr 2022)

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

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


  Commit: f8afb8fdedae04ad2670857c97925c439d47d862
      https://github.com/llvm/llvm-project/commit/f8afb8fdedae04ad2670857c97925c439d47d862
  Author: Aaron Puchert <aaron.puchert at sap.com>
  Date:   2022-04-29 (Fri, 29 Apr 2022)

  Changed paths:
    M clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h
    M clang/lib/Analysis/ThreadSafety.cpp
    M clang/lib/Analysis/ThreadSafetyCommon.cpp
    M clang/test/SemaCXX/warn-thread-safety-analysis.cpp

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


  Commit: 0314dbac026f58aaaf0a9ee4515f401f0d43ee76
      https://github.com/llvm/llvm-project/commit/0314dbac026f58aaaf0a9ee4515f401f0d43ee76
  Author: Aaron Puchert <aaron.puchert at sap.com>
  Date:   2022-04-29 (Fri, 29 Apr 2022)

  Changed paths:
    M clang/include/clang/Analysis/Analyses/ThreadSafety.h
    M clang/lib/Analysis/ThreadSafety.cpp
    M clang/lib/Sema/AnalysisBasedWarnings.cpp

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


Compare: https://github.com/llvm/llvm-project/compare/5227be8b6aa0...0314dbac026f