WGSL backend should probably emit override declarations, rather than replacing override expressions with constants

[jimblandy]

The Naga WGSL backend should probably write Module::overrides as WGSL override declarations, rather than requiring the override table to be empty, as the other backends do, under the assumption that they've been rewritten as constants.

Users who do want overrides rewritten in WGSL output can certainly apply process_overrides themselves.

In #6310, this was attempted, but it ran into trouble because of the backend's distinction between write_constant_expression, write_possibly_const_expression, and the other write_expression variants. The only reason these are separated is because we wanted to not recognize expressions we didn't expect to find in the global expression arena, but now that overrides mean that we can legitimately find a wide variety of expressions in the global expression arena, keeping those functions separate may not make much sense any more. It would be simpler for the backend write_expression functions to simply always pass around the appropriate arena.

[teoxoy]

cc @cbbowen.

I'm curious though, what is your use case for having naga ingest WGSL and produce WGSL?

[cbbowen]

I'm curious though, what is your use case for having naga ingest WGSL and produce WGSL?

I'm using naga_oil to compose shaders from one or more almost-WGSL files and produce Naga IR. I'm then using (a fork of) wgsl_to_wgpu to generate Rust bindings from that IR. All that happens at compile time. However at runtime I want to embed actual WGSL to avoid re-running or even depending on naga_oil in the client. To achieve that, I need a way to convert the IR output from naga_oil back to WGSL (or some other serializable cross-platform IR representation).