wgsl: Add validation tests for vector access of abstract types

[zoddicus]

---

Requirements for PR author:

• All missing test coverage is tracked with "TODO" or .unimplemented().
• New helpers are /** documented */ and new helper files are found in helper_index.txt.
• Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)
• Test have be tested with compatibility mode validation enabled and behave as expected. (If not passing, explain above.)

Requirements for reviewer sign-off:

• Tests are properly located in the test tree.
• Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[ben-clayton]

übernit:

Suggested change

	// error: inValid index Value
	// error: invalid index Value

[zoddicus]

Done

[ben-clayton]

Suggested change

	// error: inValid index type
	// error: invalid index type

[zoddicus]

Done

[ben-clayton]

Suggested change

	// single element conVenience name accesses
	// single element convenience name accesses

[zoddicus]

Done

[ben-clayton]

Maybe as a followup, but it would be good to check the expression type (same thing for the concrete tests), by using an explicit type for r (const r : T = V[0];).

Unlike the concrete tests, the abstract tests would need to consider that abstract-int can convert to abstract-float, but the reverse is not true.

[zoddicus]

I think I might be missing something about how abstracts in WGSL work.

I thought you couldn't explicitly type abstract int and float in WGSL, i.e. there is no way to write const r: AbstractFloat, it can only be inferred from the assignment.

And they are always constant (or override) experessions, so I cannot do something like let r = 0; r = V[0]; to check that V[0] is an AbstractInt, because though the initializer literal is a AI, it will be converted on the assignement to r to be an i32, due to the use of let.

[ben-clayton]

You're right that you can't explicitly write an abstract numeric, and I see why what I wrote is confusing.

T would be a concrete type - i32, u32, f32 etc. I was trying to point out that abstract-int could be used for any of these, but abstract-float would only work for f32.

[ben-clayton]

Maybe it would be better done as a second statement:

const C : T = r;

That would mean you still test that r gets the inferred abstract type.
You also wouldn't need to change all these individual cases, just add another statement underneath the templated case one.

[zoddicus]

I understand now. I have filed #3709 and will implement in a follow up CL.

[zoddicus]

Thinking about this, is adding a const C : T = r; statement what we want?

This wouldn't be testing the direct conversion of the swizzle of an abstract type to a concrete type (swizzle(vec<AI>) -> vec<i32>), but the conversion of vectors after the swizzle (swizzle(vec<AI>) -> vec<AI> -> vec<u32>).

I think we should already have coverage of converting an abstract vector down to a concrete one elsewhere.

For swizzle/access testingI think what we want is tests like const r : vec2<u32> = vec2(0, 0).yz;, which explictly test that a swizzle can be directly stored into a convertible type.

Does that sound correct?

[ben-clayton]

Currently we have nothing testing that the inferred type of r is as expected. The second assignment to a concrete type would validate that the inferred type is as expected.