* naga: glsl parser should return singular ParseError similar to wgsl
* wgpu: treat glsl the same as wgsl when creating ShaderModule
* naga: update glsl parser tests to use new ParseError type
* naga: glsl ParseError errors field should be public
* wgpu-core: add 'glsl' feature
* fix some minor bugs in glsl parse error refactor
* naga/wgpu/wgpu-core: improve spirv parse error handling
* wgpu-core: feature gate use of glsl and spv naga modules
* wgpu: enable wgpu-core glsl and spirv features when appropriate
* obey clippy
* naga: derive Clone in Type
* naga: don't feature gate Clone derivation for Type
* obey cargo fmt
* wgpu-core: use bytemuck instead of zerocopy
* wgpu-core: apply suggested edit
* wgpu-core: no need to borrow spirv code
* Update wgpu/src/backend/wgpu_core.rs
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
---------
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
Without the suffix, `Expression::Literal(Literal::F32)` expressions
get written without any suffix on the number, meaning that they get
re-parsed as `AbstractFloat` values. In theory, this should always be
fine, but since we don't actually support abstract types yet in all
the places we should, having them appear in the output causes
validation problems.
See also: #4863, which did the same for `i32` literals.
Without the suffix, `Expression::Literal(Literal::I32)` expressions
get written without any suffix on the decimal number, meaning that
they get re-parsed as AbstractInt values. In theory, this should
always be fine, but since we don't actually support abstract types yet
in all the places we should, having them appear in the output causes
validation problems.
Apply the `NonUniform` decoration to the results of all access chains rooted in binding arrays that use non-uniform values as indices, regardless of the binding array's element type and address space. Previously, Naga only decorated non-uniform access chains for binding arrays of buffers.
When a label in a WGSL front end error has an undefined span, omit the
label from the error message. This is not great, but because of the
way Naga IR represents local variable references it is hard to get the
right span, and omitting the label better than panicking in `unwrap`,
since the error message has a general message anyway.
When reporting errors in construction expressions, use the span of the
constructor itself (that is, the type name) in preference to the span
of the overall expression. This makes errors easier to follow.
When a constructor builtin has an explicit type parameter, like
`mat2x2<f32>`, it should not produce an abstract matrix, even if its
arguments are abstract.
