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