[naga] Add GLSL constant_id layout qualifier support and WGSL backend override output

[06wj]

Connections
No dependencies on other PRs. Please add related issues if any.

Description
This PR adds support for GLSL specialization constants (constant_id layout qualifier) in the Naga GLSL frontend and enables the WGSL backend to output override declarations.

1. GLSL Frontend

• Parse layout(constant_id = N) qualifier for const declarations
• Convert these to Naga Override instead of Constant
• Handle Override expressions in the constant evaluator

2. WGSL Backend

• Remove the "pipeline constants not supported" error
• Add write_override() method to output @id(N) override declarations
• Support Expression::Override in expression writers
• Implement write_override in TypeContext

3. Naming

• Add NameKey::Override variant for override naming

Testing

• Add spec-constant.frag test case with various specialization constant types

Squash or Rebase?

This branch contains a single functional commit and can be rebased directly.

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[teoxoy]

So, GL_KHR_vulkan_glsl allows specialization constants to be used in constants:

layout(constant_id = 18) const int scX = 1;
layout(constant_id = 19) const int scZ = 1;
const ivec3 scVec = ivec3(scX, 1, scZ);  // partially specialized vector

But does this work, would you be able to add a test for this?

I think even if we allow overrides in GlslRestrictions::Const here it won't since the validator will complain that constants use overrides in their initializers.

The GLSL frontend would have to emit overrides for all constants that (indirectly) use specialization constants.

We can of course put this off and create an issue for it, but I was just wondering.

[06wj]

Good catch! I've added the test case and you're right - it doesn't work correctly. The generated WGSL hardcodes the constant_id values (18, 19) instead of referencing the overrides.

const scVec: vec3<i32> = vec3<i32>(18i, 1i, 19i); 

Fixing this would require the GLSL frontend to track transitive dependencies on specialization constants. I think we should keep this PR focused on direct specialization constant usage (which works) and create a separate issue for this case.

Sound good?

[teoxoy]

Yeah that sounds fine but it seems it's misbehaving rather than it being a validation issue, can you try doing this for the const path so that we get an error instead (for now):

Behavior::Glsl(GlslRestrictions::Const(_)) => {
    Err(ConstantEvaluatorError::OverrideExpr)
}

[06wj]

Added the error message.

[teoxoy]

Thanks!

[teoxoy]

I think this looks good! Just left a comment.