Support diagnostic filters in WGSL (i.e., `diagnostic(…)`)

[ErichDonGubler]

We currently do not support the @diagnostic(…) attribute/diagnostic(…) directive (AKA "diagnostic filters" in the WebGPU spec.). This is a rather complicated subsystem, but it's exciting to have robust management of diagnostics in WGSL a la Rust. An example of how this is used from the spec.:

EXAMPLE: Global diagnostic filter for derivative uniformity

diagnostic(off,derivative_uniformity);
var<private> d: f32;
fn helper() -> vec4<f32> {
  if (d < 0.5) {
    // The derivative_uniformity diagnostic is disabled here
    // by the global diagnostic filter.
    return textureSample(t,s,vec2(0,0));
  } else {
    // The derivative_uniformity diagnostic is set to 'warning' severity.
    @diagnostic(warning,derivative_uniformity) {
      return textureSample(t,s,vec2(0,0));
    }
  }
  return vec4(0.0);
}

Relevant part of the spec.: Diagnostics, section 2.3

An initial implementation of this should include the derivative_uniformity rule, as the only current example of filterable trigger rules that can be managed per the spec.

Parse paths that we need to support to be spec.-compliant:

• Directive: WGSL: Implement diagnostic(…); directives and derivative_uniformity triggering rule #6148
• Attributes placements (pasted from the spec.):
  • Beginning of a compound statement.
  • Beginning of a function declaration: feat(wgsl-in): parse diagnostic(…) attributes on fns #6353
  • Beginning of an if statement.
  • Beginning of a switch statement.
  • Beginning of a switch_body.
  • Beginning of a loop statement.
  • Beginning of a while statement.
  • Beginning of a for statement.
  • Immediately before the opening brace ('{') of the loop body of a loop, while, or for loop.
  • Beginning of a continuing_compound_statement.

[ErichDonGubler]

Correspondent Firefox bug: bug 1882800

[jimblandy]

This is blocking some BabylonJS demos.

[Mutefish0]

This is blocking some Three.js demos.

[jimblandy]

I think we may want to scope this issue down to simply supporting the syntax, and including the data in the naga::Module somehow, where uniformity analysis could use it, once it's implemented.

We don't have any warnings in Naga right now. Adding the infrastructure for reporting them and filtering them will be a large project, for something we don't even do yet.

This issue's urgency comes from the fact that we can't parse valid shaders, so I think clearing that specific hurdle will be enough.

[jimblandy]

After discussion this morning, we agreed that this issue would remain as filed, and we'd file separate blocker issues for the sub-issues that we want to address immediately.