================
@@ -2245,6 +2245,36 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
 
     break;
   }
+  case Builtin::BI__builtin_hlsl_and: {
+    if (SemaRef.checkArgCount(TheCall, 2))
+      return true;
+    if (CheckVectorElementCallArgs(&SemaRef, TheCall))
+      return true;
+
+    // CheckVectorElementCallArgs(...) guarantees both args are the same type.
+    assert(TheCall->getArg(0)->getType() == TheCall->getArg(1)->getType() &&
+           "Both args must be of the same type");
+
+    // check that the arguments are bools or, if vectors,
+    // vectors of bools
+    QualType ArgTy = TheCall->getArg(0)->getType();
+    if (const auto *VecTy = ArgTy->getAs<VectorType>()) {
+      ArgTy = VecTy->getElementType();
+    }
+    if (!getASTContext().hasSameUnqualifiedType(ArgTy,
----------------
llvm-beanz wrote:

A function that can take either float or half vectors returning an error 
message:
> error: passing 'int4' (aka 'vector<int, 4>') to parameter of incompatible 
> type 'attribute((vector_size(4 * sizeof(float)))) float' (vector of 4 'float' 
> values)
Is an error that is at best incomplete.

We definitely shouldn't force changes to keep a pattern that isn't providing 
the best possible user experience. I don't believe it is at all subjective to 
say that this diagnostic strongly implies that the `__builtin_hlsl_cross` 
builtin only accepts `float` values, when it also accepts `half`.

I will acknowledge that calling the diagnostic "terrible" was inappropriate and 
subjective, and I apologize of that. This diagnostic (and others) being in line 
with a pattern that other HLSL builtins have been using isn't a good 
justification because it is far from the pattern used by other Clang builtins, 
and many clang builtins have significantly more robust diagnostics. For 
example, the `err_typecheck_expect_scalar_or_vector` diagnostic reports that a 
scalar type was used when a vector type was required, or the widely used 
`err_builtin_invalid_arg_type`, which has a whole bunch of variations to 
provide concrete details about the expected type of the builtin argument.

https://github.com/llvm/llvm-project/pull/127098
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to