================
@@ -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
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to