[clang] [HLSL] Implement the `lit` intrinsic (PR #134171)

[Deric C. via cfe-commits]

================
@@ -280,6 +280,22 @@ constexpr bool4 isinf(double4 V) { return isinf((float4)V); }
 _DXC_COMPAT_TERNARY_DOUBLE_OVERLOADS(lerp)
 _DXC_COMPAT_TERNARY_INTEGER_OVERLOADS(lerp)
 
+//===----------------------------------------------------------------------===//
+// lit builtins overloads
+//===----------------------------------------------------------------------===//
+
+template <typename T>
+constexpr __detail::enable_if_t<__detail::is_arithmetic<T>::Value &&
+                                    (__detail::is_same<double, T>::value ||
----------------
Icohedron wrote:

> ^ Since bool is arithmetic, both of these options would allow bool inputs to pass. I checked the [DXC implementation](https://godbolt.org/z/Eb3vTdvvG) and I guess it technically accepts bool types and casts them down to float. But is that something we want to be mimicking?
> 
> As for checking just `__detail::is_arithmetic<T>`, this produces a `call to 'lit' is ambiguous` error. So if we want to do this I think it would have to be checking not half or float too.

Thinking back on the handling of this ambiguity, I change my mind. I don't think trying to hack the implementation to mimic DXC is the right decision. It should be better to accept that the program will not compile when the method resolution is ambiguous. This is the stance we have adopted for handling ambiguous overload resolution. See [hlsl spec proposal 0020](https://github.com/microsoft/hlsl-specs/blob/63c6a33d4be91e1617d662b61be79a16693db504/proposals/0020-hlsl-202x-202y.md?plain=1#L95-L100):

> [Clang] HLSL's overload best-match algorithm ... will produce ambiguous resolution errors instead of potentially
choosing an unexpected overload when ambiguity exists in the source.


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