Improve the sensitivity of the array_zero_value tests

[andyleiserson]

In the cases where valid = true, we want to test with a const declaration, to ensure that the constructor is supported in const exprs. But in cases where valid = false, some of the subject types are not constructible, and may be rejected in a const declaration for that reason, even if the implementation is not properly restricting the use of zero-value constructors.

This changes the test to use const when valid = true and let when valid = false, which make the the tests more sensitive to the functionality they are intending to cover.

Tests still pass in Chrome. The valid_array case is failing in Safari either with or without this change. With this change, the invalid_rta, invalid_override_array, and invalid_atomic cases fail in Firefox, which I believe accurately reflects defects in the implementation.

---

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.
• Test descriptions are accurate and complete.
• Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• Tests avoid over-parameterization (see case count report).

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

[github-actions]

Results for build job (at 8b7a140):

-webgpu:shader,validation,expression,call,builtin,value_constructor:array_zero_value:* - 9 cases, 9 subcases (~1/case)
-webgpu:shader,validation,expression,call,builtin,value_constructor:array_value:* - 9 cases, 9 subcases (~1/case)
-webgpu:shader,validation,expression,call,builtin,value_constructor:struct_zero_value:* - 8 cases, 8 subcases (~1/case)
-webgpu:shader,validation,expression,call,builtin,value_constructor:struct_value:* - 8 cases, 8 subcases (~1/case)
+webgpu:shader,validation,expression,call,builtin,value_constructor:array_zero_value:* - 27 cases, 27 subcases (~1/case)
+webgpu:shader,validation,expression,call,builtin,value_constructor:array_value:* - 27 cases, 27 subcases (~1/case)
+webgpu:shader,validation,expression,call,builtin,value_constructor:struct_zero_value:* - 24 cases, 24 subcases (~1/case)
+webgpu:shader,validation,expression,call,builtin,value_constructor:struct_value:* - 24 cases, 24 subcases (~1/case)
-TOTAL: 285746 cases, 2344638 subcases
+TOTAL: 285814 cases, 2344706 subcases

[alan-baker]

Does the sensitivity come from putting them in a function or must it also use let?

[andyleiserson]

Making it const inside the function could still raise a "not legal in const context" error and pass the test on that basis.

Although, it's not clear to me that there's as strong a distinction between the validation in these cases as I was originally thinking. I think naga should be raising the error it raises in const context ("type not constructible") for the let decls as well.

I noticed this isssue because in reviewing gfx-rs/wgpu#8741 I went looking for a CTS test that would fail before the change, and found this test, but it wasn't failing. But I do understand that balancing the sensitivity of the tests vs. simplicity and clarity of the test cases is a tradeoff, it is okay with me if you don't want to take this change.

[alan-baker]

Not necessarily. I almost wonder if we should have two versions (subcases) of the test since it sounds like they might be able to catch different problems. I'll leave that as optional though. Let me know if you want to make that change. If not, we can just get the branch up-to-date and merge it.