================
@@ -7941,6 +7942,32 @@ static bool handleFunctionTypeAttr(TypeProcessingState
&state, ParsedAttr &attr,
return true;
}
+ if (attr.getKind() == ParsedAttr::AT_CFISalt) {
+ if (attr.getNumArgs() == 0)
+ return true;
+
+ // Delay if this is not a function type.
+ StringRef Argument;
+ if (!S.checkStringLiteralArgumentAttr(attr, 0, Argument))
+ return false;
+
+ // Delay if this is not a function type.
+ if (!unwrapped.isFunctionType())
+ return false;
+
+ const auto *FnTy = unwrapped.get()->getAs<FunctionProtoType>();
+ if (!FnTy)
----------------
AaronBallman wrote:
> I wouldn't expect an attribute that doesn't pass the builtin-TableGen'd
> stuff to reach this function (like for arg counts/appertainment/etc), so if
> this IS getting here, it either needs to diagnose here, or figure out WHY
> we're continuing after failing tablegen.
Type attributes do not have as much automagical hookup with tablegen as
declaration attributes; so IIRC all of them have to do manual processing like
this. So I do expect to get here (at least, with my psychic debugger), and I
think we likely need to diagnose explicitly.
https://github.com/llvm/llvm-project/pull/141846
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits