================
@@ -4912,3 +4922,279 @@ void AutoType::Profile(llvm::FoldingSetNodeID &ID,
const ASTContext &Context) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::~FunctionEffect() = default;
+
+bool FunctionEffect::diagnoseConversion(bool Adding, QualType OldType,
+ FunctionEffectSet OldFX,
+ QualType NewType,
+ FunctionEffectSet NewFX) const {
+ return false;
+}
+
+bool FunctionEffect::diagnoseRedeclaration(bool Adding,
+ const FunctionDecl &OldFunction,
+ FunctionEffectSet OldFX,
+ const FunctionDecl &NewFunction,
+ FunctionEffectSet NewFX) const {
+ return false;
+}
+
+bool FunctionEffect::diagnoseMethodOverride(bool Adding,
+ const CXXMethodDecl &OldMethod,
+ FunctionEffectSet OldFX,
+ const CXXMethodDecl &NewMethod,
+ FunctionEffectSet NewFX) const {
+ return false;
+}
+
+bool FunctionEffect::canInferOnDecl(const Decl *Caller,
+ FunctionEffectSet CallerFX) const {
+ return false;
+}
+
+bool FunctionEffect::diagnoseFunctionCall(bool Direct, const Decl *Caller,
+ FunctionEffectSet CallerFX,
+ CalleeDeclOrType Callee,
+ FunctionEffectSet CalleeFX) const {
+ return false;
+}
+
+const NoLockNoAllocEffect &NoLockNoAllocEffect::nolock_instance() {
+ static NoLockNoAllocEffect global(kNoLockTrue, "nolock");
+ return global;
+}
----------------
Sirraide wrote:
> another limitation of AttributedType is that it doesn't seem to hold anything
> more than the attribute kind
The attribute itself appears to usually be stored in an `AttributedTypeLoc`
rather than as part of the type itself.
> two bugs where the sugar gets stripped, e.g. on an auto lambda
It seems we’re taking care to try and preserve `AttributedType`s in several
places, so that does sound like it might be a bug; we should probably fix those
(unless there’s a good reason why we’re stripping the attributes there).
> I got some guidance that the `true` forms of the attributes made sense as
> part of the canonical type
I agree that that makes sense, yeah.
> Even if FunctionEffect turns out to be just some bits controlling details of
> the behavior, rather than a vtable, it's still attractive to me to
> encapsulate it into a uniqued object with methods, to centralize all those
> behaviors.
I’ll take another look at how it’s currently used; I’d also like to hear what
other people (for instance Aaron) have to say about this; I already pinged him
in one of the comments below that’s also about this.
https://github.com/llvm/llvm-project/pull/84983
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
