[clang] [HLSL] Implement the 'and' HLSL function (PR #127098)

[Farzon Lotfi via cfe-commits]

================
@@ -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,
----------------
farzonl wrote:

>This actually doesn’t express my concern because you don’t know the expected type. There is no way to know it from the context available.

We know the expected types because we have defined them in sema per builtin. Thats how `CheckAllArgsHaveFloatRepresentation`,  `CheckFloatOrHalfRepresentations`,  `CheckUnsignedIntRepresentation` came to be in the first place. The Expected types are specified in these sema rules.  and a spot check to  `hlsl_intrinsics.h`  should show they are the correct expected types.

> Instead in the hand-rolled builtin diagnostics we're arbitrarily choosing an "expected" type and not explaining to the user that there were more than one valid options.

`CheckFloatOrHalfRepresentations` currently used by `cross`  is a wrapper for `CheckArgTypeIsCorrect`. The problem you raised about alerting on `float` and not`half` is caused because we are only passing one expected type to CheckArgTypeIsCorrect. Changing this to a list allows us to do a diangostic per expected type. 

Further switching to using `CheckScalarOrVector`  has the same problem  switching to it in the cross case would force you to do an error diagnostic on a "arbitrarily expected" type.



https://github.com/llvm/llvm-project/pull/127098