asuint doesn't accept signed integer vector literals

[sudonatalie]

Description
Validation fails when asuint is passed a vector literal of signed integers. Of course, this is something that only comes up in generated code where the literal isn't known ahead of time. If this is intended behavior, it seems like at least the error messaging should be improved.

Steps to Reproduce
dxc -T cs_6_6

RWByteAddressBuffer prevent_dce : register(u0);

[numthreads(1, 1, 1)]
void main() {
  int arg = -1;
  int3 vec = (-1).xxx;
  prevent_dce.Store3(0u, arg); // !!! WORKS
  prevent_dce.Store3(0u, asuint(-1)); // !!! WORKS
  prevent_dce.Store3(0u, vec); // !!! WORKS
  prevent_dce.Store3(0u, asuint((-1).xxx)); // !!! FAILS
  return;
}

https://godbolt.org/z/YcE8c1hqa

Expected Behavior
Compilation succeeds, or a relevant error message is produced.

Actual Behavior

error: validation errors
Invalid record
Validation failed.

Environment

• DXC version: libdxcompiler.so: 1.8(dev;4705-99f2d498)
• Host Operating System: Linux

[llvm-beanz]

This one works in 202x. Unsure what exactly is happening here, but this is likely some odd explosion of the literal to 64-bits. We have some known issues with storing literals to ByteAddressBuffer causing 64-bit stores instead of 32-bit stores (see: #5493).

I don't know if you're going to want to adopt an experimental in-development language version, but HLSL 202x fixes this issue as part of this feature proposal (https://github.com/microsoft/hlsl-specs/blob/main/proposals/0017-conforming-literals.md)

[damyanp]

As this is fixed in 202x, no plans at moment to go back and address this for older language versions. Happy to hear feedback on why we should consider this higher priority.

[sudonatalie]

No problem, we're working around it by extracting the literal to a var.