[naga wgsl-in] Experimental 64-bit floating-point literals.

[jimblandy]

In the WGSL front end, support an l suffix on floating-point literals to yield 64-bit integer literals.

Unless Capabilities::FLOAT64 is selected, these literals will always be validated out, so it doesn't affect standards compliance.

This PR is questionable. I guess it's nice to have f64 support to play with (edit: and the front and back ends already parse and emit an f64 WGSL type), but it's hardly urgent. Who knows whether the spec will ever actually have f64 support, and if it does, what the syntax will be?

But the truth is, I have ulterior motives for this patch. It's a little circuitous:

• On the abstract type branch, all constructor built-in functions know how to consume abstract values. Calls to scalar constructor built-in functions (say, f32(5)) are handled by generating As expressions and letting the constant evaluator convert abstract values to concrete values. So f32(5) constant-evaluates the AbstractInt 5 to the f32 5.0.
• It happens that the test case tests/out/wgsl/double-math-functions.frag.wgsl contains expressions like f64(1.0). It's translated from GLSL, which does have a double type.
• Naga should either accept f64(1.0) or reject it.
  • If Naga rejects it, then we cannot translate tests/in/glsl/double-math-functions.frag to WGSL. The GLSL snapshots aren't really set up to generate other output languages; I don't really want to change that. Fine, maybe we back this test out, it's hardly essential. But let's assume that we want to accept it.
  • If Naga accepts it, then the only reasonable semantics for this expression should be that applying the f64 constructor built-in function to an AbstractFloat gives you an f64.
• ConstantEvaluator::cast doesn't happen to support casting to f64. Since it returns an error, the WGSL front end assumes that the expression is not constant-evaluatable, and leaves it in the IR as anAbstractFloat literal, which the validator then rejects.
• Expanding ConstantEvaluator::cast to support casting to f64 allows the out/wgsl file to validate.
• However, it also means that Literal::F64 values start making it to the WGSL backend, which errors out because WGSL has no f64 literal syntax. Hence the present PR.

So it seems to me we have two options:

• Give WGSL syntax for 64-bit literals, and have it generate them in tests/out/wgsl/double-math-functions.frag.wgsl and then read and validate them.
• Remove tests/in/glsl/double-math-functions.frag and forget all this.

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[jimblandy]

Point in favor of this PR: It seems like the front and back ends already support an f64 WGSL type. We just don't have a syntax for literals of that type.

If we do feel that adding experimental f64 support is okay, then it would probably make sense to pair it with backend support for literals as well. There should then be snapshot tests for the literals too.

[cwfitzgerald]

Speaking from community side, having support for this is one step closer to end-to-end f64 support, something that is asked for a decent amount, particularly from the scientifically minded folks.

[teoxoy]

• Give WGSL syntax for 64-bit literals, it generate them in tests/out/wgsl/double-math-functions.frag.wgsl and then read and validate them.

I'm also in favor of supporting f64 👍

[jimblandy]

Okay, here's full front and back end support with an lf suffix.