wgsl: Change 'abstract' -> 'abstract_float'

[zoddicus]

This avoids confusion with 'abstract_int'

Fixes #3184

---

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.)

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]

It's not clear to me why the cache files have changed. Renaming fields in the code shouldn't affect the serialized cases.

[ben-clayton]

This feels unnecessary. FP is floating-point. It would make little sense for FP.abstract to refer to anything but abstract-float.

[zoddicus]

It is because we do things like FP[kind] to get a specific instance for a fp type , where kind is originating as string from a permutation of the test parameters. So there currently exists a potential conflict between abstract float and abstract int tests in the same .spec.ts for a builtin. (I don't think there exists any occurances at the moment, since the abstract_int tests haven't been written).

There are a number of options to resolve this:

1. Leave as is, and just add abstract_int when needed in other parts of the tests, and people will just need to know that 'abstract' means abstract float.
2. Push the change all the way down through the CTS, and change the naming from abstract to abstract_float everywhere (which is what I am doing in this test), so it is unambigious if we are dealing with abstract_float vs abstract_int.
   (Would using af instead of abstract_float be more appealing? Since we are already include that it is a float in f16 and f32)
3. Have some sort of switching logic for getting a element out of the FP set that converts from abstract_float to abstract
4. Split up tests so that we never have abstract float and abstract int being tested in the same file. This might work, though will still require some cognitive load to remember which abstract the context is refering to. And there is probably a bunch of internal places to the CTS where the distinction needs to be clear that will make it crufty.

[ben-clayton]

It is because we do things like FP[kind] to get a specific instance for a fp type , where kind is originating as string from a permutation of the test parameters.

But you're going to have to do something to switch between FP[kind] and Int[kind], no?

[jiangzhaoming]

Currently when we test built-ins (e.g. abs) that can take either abstract float or abstract integer as input type, we do have separated tests for integer and float types (but within a single .spec.ts file), naming the abstract float test abstract_float while accessing FP.abstract during case generating. In these case I think naming integer tests abstract_int will just work fine?

If we are going to have a more general dictionary that includes all FP and int types (like below?), maybe we can just make distinction in that dictionary, and those tests use this dictionary can use distinct parameter strings abstract_float and abstract_int. For those tests that just focus on FP or int but not both, I think a single abstract will not cause confusion?

A possible general dictionary(?) :

export const NumericTypes = {
    'f32': FP.f32,
    'f16': FP.f16,
    'abstract_float': FP.abstract,
    'i32': Int.i32,
    'u32': Int.u32,
    'abstract_int': Int.abstract,
};

[zoddicus]

I agree with both of your points/suggestions. This PR is not the way forward on this. This can be addressed when it comes up using something like the suggested dictionary or simple switching logic, without the overall cost of change everything.