Fix typing for select

[ErichDonGubler]

Connections

• Depends on feat(naga): constant evaluation for select #7602.
• Resolves Automatic type conversion not working for select #7538.

Testing

Tests have been added, as well as a test run against webgpu:shader,execution,expression,call,builtin,select:* in a locally modified Firefox.

Squash or Rebase?

rebase plz

Checklist

• If this contains user-facing changes, add a CHANGELOG.md entry.

[ErichDonGubler]

Migrated from #7602 (comment): @jimblandy was wondering if we really needed cast here. So far as I can tell...yes.

[ErichDonGubler]

Ah, another issue: We apparently coerce 0 and non-zero numeric values to bool with cast. That makes select accept strictly more things than it should in constant evaluation; is there a reason we should allow such a cast?

[ErichDonGubler]

@jimblandy: Poke on this.

[jimblandy]

When we lower an AST expression to a Naga IR expression, we preserve its span. You can use ctx.get_expression_span(lowered_expr) to get these spans, so there's no need to retain the foo_orig handles.

[ErichDonGubler]

I had originally authored this PR using get_expression_span on lowered expression handles, but I actually found gaps in the spans returned. For many runtime expressions in the tests I'm adding, we instead get Span::default() instead of the expected spans. 😐

I'd be happy to figure this particular issue out with you, but I suspect that it will need further work that's orthogonal to this PR. I don't think this should be blocking.

[ErichDonGubler]

Implemented this change (outside this PR) and changed tests to demonstrate the regressions: c449dd0

[ErichDonGubler]

Ah, this seems to be because the span lookup for locals appears to try to use something other than the span of the identifier referring to those locals; writing some quick debug diagnostics (fe60016) against this shader:

fn select_arrays(which: bool) -> i32 {
  var x: array<i32, 4>;
  var y: array<i32, 4> = array(1, 2, 3, 4);
  let s = select(x, y, which);
  return s[0];
}

…yields this output:

error: before
  ┌─ wgsl:4:18
  │
4 │   let s = select(x, y, which);
  │                  ^

error: after

error: before
  ┌─ wgsl:4:21
  │
4 │   let s = select(x, y, which);
  │                     ^

error: after

error: before
  ┌─ wgsl:4:24
  │
4 │   let s = select(x, y, which);
  │                        ^^^^^

error: after
  ┌─ wgsl:1:18
  │
1 │ fn select_arrays(which: bool) -> i32 {
  │                  ^^^^^

Could not parse WGSL:
error: unexpected argument type for `select` call
 = note: expected a scalar or a `vecN` of scalars

…where before and after diagnostics should be pointing to the same span, but they don't. If it's true that get_expression_span should be returning the same span as the expression used to get the ir::Handle, it looks like we have some nontrivial changes to make.

[jimblandy]

This is a known limitation, filed as #7498. When we fix that, these diagnostics will magically get better.

You can work around it in your tests by making the operand more complex than a variable reference, like y + 0 or something.

[ErichDonGubler]

...but why would I accept bad diagnostics for something that's easy to migrate to once fixed? I'd strongly prefer that this code be migrated to get_expression_span after it's fixed, because the diagnostics are okay right now. 😭