ConstantBuffer.Length gives shader compilation error

[BobSammers]

Description (optional)

ConstantBuffer<T> has a .Length property, but I get a shader compile error when I try to access it for a buffer of uints.

Reproduction Steps

Attempt to compile a shader with the following code

[ThreadGroupSize(DefaultThreadGroupSizes.XY)]
[GeneratedComputeShaderDescriptor]
internal readonly partial struct Trial(
        ReadWriteTexture2D<uint> pixelBuffer,
        ConstantBuffer<uint> colourMap,
        int xMax
    ) : IComputeShader
{
    public void Execute()
    {
        var index = (int)(ThreadIds.X / (float)xMax * colourMap.Length);
        pixelBuffer[ThreadIds.XY] = colourMap[index];
    }
}

Expected Behavior

Shader is correctly compiled.

Actual Behavior

Compilation fails:

Message: "The DXC compiler encountered one or more errors while trying to compile the shader: "

error: invalid format for vector swizzle 'GetDimensions' resource.GetDimensions(_0, _1);

[error]: no matching function for call to '__get_Dimension0'

int index = (int)(ThreadIds.x / (float)xMax * __get_Dimension0(colourMap));
~~~~~~~~~~~~~~~ static int __get_Dimension0(uint resource) .

Using the current stable version (2.1.0), this occurs at run time; using 3.0.0-preview2 results in errors as soon as the code is typed.

System info

This section should contain useful info such as:

• ComputeSharp
  • 2.1.0. / 3.0.0-preview2 (ComputerSharp.Dynamic @ 2.1.0 / 2.2.0-preview1)
• Operating system version:
  • Win 11 Pro 22621.3447
• CPU/GPU model (the latter is especially useful for shader issues)
  • Intel 8th Gen / Intel HD530
• Visual Studio version, or .NET SDK/runtime version
  • VS2022 17.9.6 / .net8.0

Additional context (optional)

It may be that ConstantBuffer<T> is not the best type to use in this scenario (I have no experience in shader programming), but as the Length property is provided in a C# class specifically intended for creating shaders, I'm assuming it is a bug if it cannot be translated into valid HLSL. Using a ReadOnlyBuffer<T> instead in otherwise identical code works as expected, and the example compiles and runs with expected results.