This is an archive of the discontinued LLVM Phabricator instance.

Thread safety analysis: Store capability kind in CapabilityExpr
ClosedPublic

Authored by aaronpuchert on Apr 20 2022, 2:44 PM.

Details

Summary

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).

Diff Detail

Event Timeline

aaronpuchert created this revision.Apr 20 2022, 2:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2022, 2:44 PM
aaronpuchert requested review of this revision.Apr 20 2022, 2:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2022, 2:44 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
aaron.ballman added inline comments.Apr 22 2022, 12:29 PM
clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h
277

Hrmmmm, I think this may actually be safe, but it does give me pause to store a StringRef as anything other than a local (or param/return type): https://llvm.org/docs/ProgrammersManual.html#the-stringref-class

Can you double-check my thinking? This is fine because it's pulling the StringRef from the CapabilityAttr, and that stores its name internally and isn't released until the AST is destroyed.

aaronpuchert added inline comments.Apr 22 2022, 4:35 PM
clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h
277

Exactly, aside from two places where I'm storing a string literal ("mutex" and "wildcard"), the common case is taking the StringRef (as returned by CapabilityAttr::getName) from the attribute. So that would be lifetime-coupled to the AST and should be safe for our analysis.

Of course StringRef is implicitly constructible from other types, and we wouldn't want that. Especially std::string would be an issue. Perhaps we should prevent implicit conversions, and thus force the caller to pass a StringRef glvalue, by overloading with a deleted template?

template<typename T>
CapabilityExpr(const til::SExpr *, T, bool) = delete;

Or maybe you've got a better idea.

As for a justification: we're building lots of CapabilityExprs, essentially every time we see a capability expression in the code (in attributes or as capability type method call arguments). Given that the kind is only used for actual warnings I wouldn't want us to spend of lot of time or memory on storing it.

We could also store the original Expr* and extract on demand, but that seemed to me antithetical to translating into the TIL. Of course it would be slightly faster, but the current code (before this change) also extracts capability names eagerly without waiting for the need to arise.

aaron.ballman accepted this revision.Apr 25 2022, 4:54 AM

LGTM with the extra safety measure added. I'm happy to review again if you'd like, but don't require it.

clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h
277

Of course StringRef is implicitly constructible from other types, and we wouldn't want that. Especially std::string would be an issue. Perhaps we should prevent implicit conversions, and thus force the caller to pass a StringRef glvalue, by overloading with a deleted template?

I think that's likely a good safety measure, good suggestion!

As for a justification:

Oh, I already thought it was well-motivated, I just wanted to make sure I wasn't wrong about the lack of lifetime issues. :-)

This revision is now accepted and ready to land.Apr 25 2022, 4:54 AM
This revision was automatically updated to reflect the committed changes.
aaronpuchert marked 2 inline comments as done.