* 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.
Delete the `first_component_ty_inner` field from
`front::wgsl::lower:🚧:Components::Many`. With the
introduction of abstract types, it will no longer be possible to infer
the type of the vector being constructed by looking at the type of its
first constructor argument alone: automatic conversion rules might
need to be applied to that argument.
The large `match` statement in `Lowerer::construct` seems to flop back
and forth between two indentation levels as it's edited, making the
diffs hard to read. Rewrite it to use deferred initialization of
`expr`, so that `cargo fmt` doesn't have to decide whether or not to
put the `match` on the same line as `let expr`. This makes subsequent
diffs easier to read.
Have `compact::compact` preserve entries in the `Module::types` arena
if they have names.
Future abstract type support will require the WGSL front end to
compact the module before validation. Without this change, that will
drop `alias` declarations, making it harder to test type validation.
Previously, implicit padding members of `struct`s were suppressed from
structure definitions in Metal output if they had a binding specified
for them (i.e., `@location(0)`). This padding is, however, is necessary
for correct access of member fields passed into shaders by uniform and
storage buffers. Unconditionally emit padding members for `struct`s.
Resolves
[`gfx-rs/wgpu`#4701](https://github.com/gfx-rs/wgpu/pull/4701).
Test Naga's WGSL front end's handling of `h` and `f` suffixes on
hexadecimal float literals. WGSL permits these suffixes only if an
exponent is present, because otherwise `f` suffixes can be confused
with a hexadecimal digit.
Following Rust convention, let `naga::front::wgsl::ParseError`'s
methods `emit_to_stderr_with_path` and `emit_to_string_with_path`
accept any `AsRef<Path>` argument as the path.
Pass input paths in snapshot tests, so that failures processing
shaders name the input file being processed.
Change the WGSL code in the `function_returns_void` test in
`tests/wgsl-errors.rs` so that the construction expression types
correctly. Subsequent iterations of the WGSL front end will be doing
some type checking earlier, to support WGSL's automatic conversions,
and without this fix, this test will stop checking what it is intended
to check.
Let `naga::TypeInner::Matrix` hold a full `Scalar`, with a kind and
byte width, not merely a byte width, to make it possible to represent
matrices of AbstractFloats for WGSL.
Add an `I64` variant to `crate::Literal`, making `crate::Expression`
suitable for representing `AbstractFloat` and `AbstractInt` values in
the WGSL front end.
Make validation reject uses of `Literal::I64` in constant and function
expression arenas unconditionally. Add tests for this.
Let the frontends and backends for languages that have 64-bit integers
read/write them.
When asked to evaluate an `Expression::As` cast applied to a `Splat`
expression, change `ConstantEvaluator::cast` to preserve the `Splat`,
rather than expanding it out to a `Compose` expression.
When formatting `TypeInner::Pointer` and `TypeInner::Array` as WGSL
source code, bother to actually generate text for the target/element
type. This avoids producing ridiculous messages like:
> the type of `foo` is expected to be `array<unknown, 2>`, but got `array<unknown, 2>`
When generating WGSL for an `Expression::Compose` constructing a
matrix, consult `TypeInner::Matrix::width` when writing the
type name in the construction expression, rather than just always
writing `matNxM<f32>`.
Fixes#4681.
The second argument of the GLSL `ldexp` builtin is always a 32-bit
integer or a vector of such, never a 64-bit integer. In
`inject_common_builtin`, that argument's type should not be influenced
by `float_width`.
Fixes#4680.
The first argument of the `dot`, `reflect`, `distance`, and `ldexp`
GLSL builtin functions may be either a float or a double, and thus the
argument type registered by `inject_common_builtin` must depend on the
`float_width` argument; it cannot simply be `Scalar::F32`.
Introduced by #4673.
Replace `ExpressionContext`'s methods `format_typeinner`,
`format_type`, and `format_type_resolution` with more `to_wgsl`
methods in the `naga::front::wgsl::to_wgsl` module.
Clean up some things that should have been taken care of in the
original PR:
- Use `Scalar::float` helper.
- Use `Scalar` associated constants in match patterns.
- Use `Scalar`'s `PartialEq` implementation.
- Clean up identifier paths.
Identify reachable function expressions, constant expressions, and
types using a single pass over each arena, taking advantage of the
fact that expressions and types may only refer to other entries that
precede them within their arena. Only walking the statement tree still
requires a worklist/recursion.
In addition to presumably being faster, this change slightly reduces
the number of non-comment lines of code in `src/compact`.
Introduce a new struct type, `Scalar`, combining a `ScalarKind` and a
`Bytes` width, and use this whenever such pairs of values are passed
around.
In particular, use `Scalar` in `TypeInner` variants `Scalar`, `Vector`,
`Atomic`, and `ValuePointer`.
Introduce associated `Scalar` constants `I32`, `U32`, `F32`, `BOOL`
and `F64`, for common cases.
Introduce a helper function `Scalar::float` for constructing `Float`
scalars of a given width, for dealing with `TypeInner::Matrix`, which
only supplies the scalar width of its elements, not a kind.
Introduce helper functions on `Literal` and `TypeInner`, to produce
the `Scalar` describing elements' values.
Use `Scalar` in `wgpu_core::validation::NumericType` as well.
Introduce a new struct `Scalar`, holding a scalar kind and width, and
use it as appropriate in the WGSL front end. This consolidates
many (kind, width) pairs, and lets us name the two components.
Ideally, `Scalar` would be used throughout Naga, but this would be a large
change, touching hundreds of use sites. This patch begins by
introducing `Scalar` to the WGSL front end only.
This appears to match other backends, and fixes
fix the case where expressions which were named in earlier
functions are used in local variable declarations
Replace the `TypedExpression` struct, used to distinguish between WGSL
pointers and references since Naga has only `Pointer`, with an enum,
`Typed`, with variants for references and plain types. This cleans up
a bunch of code, since the struct's `is_reference` field basically
served as a detached enum discriminant. This also prepares the code
for adding abstract types.
When an error snapshot test fails and we generate a diff comparing the
expected output with the actual output, treat the expected output as
the diff "from", and the actual output as the diff "to" - not the
reverse.
