sagudev
sagudev
[CTS results from servo](https://github.com/sagudev/servo/actions/runs/10578336753): ``` OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,decl,const:function_scope:* PASS [expected FAIL] subtest: : OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,access,array:early_eval_errors:* PASS [expected FAIL] subtest: :case="const_func_in_bounds" OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,access,matrix:early_eval_errors:* PASS [expected FAIL] subtest: :case="const_func_in_bounds" OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,access,vector:abstract:* FAIL [expected...
`webgpu:shader,validation,expression,access,vector:abstract:*` failures are https://github.com/gfx-rs/wgpu/issues/4400 `webgpu:shader,validation,expression,binary,bitwise_shift:shift_left_concrete:*` fails because https://github.com/gfx-rs/wgpu/issues/6175
> I suspect that const. eval. is actually rejecting that code properly, but we're not treating the error as fatal in WGSL parsing That would be true, if I didn't...
Per https://gpuweb.github.io/gpuweb/wgsl/#bit-expr we need to report overflow when value goes into sign bits, while rust's `checked_shl` only reports overflow when its out of bits.
> …but this doesn't need to block this PR from getting merged, right? Right.
any progress? I do not want to create more conflicts.
This happens on both compute/render pipeline.
I tested repro with https://github.com/gfx-rs/wgpu/pull/6280 and while it does not panic it still raises validation error (per CTS it should return appropriate bind group), so please reopen the issue.
The problem is that `usage = 0`: https://github.com/gfx-rs/wgpu/blob/9f85f8aeea6c43c1a412bafc8fbcfb43aad0dd20/wgpu-core/src/validation.rs#L897-L900 for compute pipeline with: ```wgsl @group(0) @binding(0) var binding: f32; @compute @workgroup_size(1) fn main( @builtin(global_invocation_id) id: vec3 ) { _ = binding;...