This issue is spawned on the intersection of #1315 (comment) and #1571. Both Tint and Naga, when processing SPIR-V (on the input), generate internal representations that:

• introduce a private global variable for each input or output global in SPIR-V
• wrap every entry point function, so that the prelude first copies inputs into the private globals, then runs the real entry point, and after that copies the private globals into the outputs, which are returned.

Brief example:

var<private> _frag_color : vec4<f32>;
var<private> _in_color : vec4<f32>;

// translated directly from SPIR-V
fn _foo() {
  _frag_color = _in_color;
}

// our wrapper
[[stage(fragment)]]
fn foo([[location(0)]] in_color: vec4<f32>) -> [[location(0)]] vec4<f32> {
  _in_color = in_color
  _foo();
  return _frag_color;
}

See Tint docs for details and other examples.

This is a problem right now because the uniformity analysis doesn't consider private globals to be uniform. So a valid SPIR-V program that, for example, uses workgroup_id builtin, would turn in WGSL code that doesn't pass uniform control flow validation, since the mirror private global would never be considered uniform.

One could argue that this isn't a problem with WGSL spec (SPIR-V -> WGSL path is less priority than WGSL -> anything), or that it's an implementation problem (could generate smarter code to avoid the private globals). I think it's fair to characterize this as an "ecosystem" problem, since people would want to convert their shaders to WGSL, and they will end up with a lot of previously valid code that fails to validate properly.