================
@@ -271,26 +271,32 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair<const til::SExpr *, 1, bool> CapExpr;
+ /// The capability expression and flags.
+ llvm::PointerIntPair<const til::SExpr *, 2, unsigned> CapExpr;
/// The kind of capability as specified by @ref CapabilityAttr::getName.
StringRef CapKind;
public:
- CapabilityExpr() : CapExpr(nullptr, false) {}
- CapabilityExpr(const til::SExpr *E, StringRef Kind, bool Neg)
- : CapExpr(E, Neg), CapKind(Kind) {}
+ static constexpr unsigned FlagNegative = 1u << 0;
+ static constexpr unsigned FlagReentrant = 1u << 1;
----------------
aaronpuchert wrote:
While I see your point, this is all a bit vague. The purpose of negative
capabilities is
[documented](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#negative) as
helping to prevent double locking, which is not an issue for reentrant mutexes.
> I've been on the receiving end of such forced restrictions, and it's rather
> annoying
The other side of the coin is that it is very hard to make the analysis more
strict after we've released a feature, while making it more permissive is not a
problem. Having done a few breaking changes myself, it's something that I'd
like to avoid as much as possible.
That's why I tend to err on the side of making the analysis as strict as it can
be while still being useful, and if that causes too much friction relax it
later.
In this case, the restriction doesn't seem arbitrary at all. The combination
simply doesn't make sense by the documented purpose of negative capabilities.
https://github.com/llvm/llvm-project/pull/137133
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
