- The Typifier was updated to expect `uint`
- Both `glsl` and `spv` frontends where updated to cast the result to `sint`.
- Both `glsl` and `spv` backends where updated to cast the result to `uint`.
- Remove cast in `msl` backend.
Glsl defines under `Function Definitions` (Paragraph 6.1 in glsl 4.60),
the following:
> When function calls are resolved, an exact type match for all
> the arguments is sought.
> (...)
> If no exact match is found, then the implicit conversions in
> section “Implicit Conversions” will be applied to find a match.
> (...)
> Mismatched types on output parameters (out or inout) must have a
> conversion from the formal parameter type to the calling argument type.
The glsl frontend wasn't performing this implicit cast for output parameters.
This commit fixes that by using a proxy write, this
creates a spill variable with the correct type and in the call
prologue a conversion is made back to the original type and the
value is stored in the original variable.
Make changes suggested in #2075, but put off to a separate PR because they would interfere with reviewing the change:
- Split the new WGSL front end into modules in a logical way.
- Rename `Parser` to `Frontend`.
[Since Rust 1.58], Rust format strings have been able to "capture
arguments simply by writing {ident} in the string." Clippy 1.67 made
the corresponding warning, `uninlined_format_args`, warn-by-default.
Inlined arguments seem more readable, so Naga should adopt them.
[Since Rust 1.58]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1580-2022-01-13
Fixes#1745: Support out-of-order module scope declarations in WGSL
Fixes#1044: Forbid local variable shadowing in WGSL
Fixes#2076: [wgsl-in] no error for duplicated type definition
Fixes#2071: Global item does not support 'const'
Fixes#2105: [wgsl-in] Type aliases for a vecN<T> doesn't work when constructing vec from a single argument
Fixes#1775: Referencing a function without a return type yields an unknown identifier error.
Fixes#2089: Error span reported on the declaration of a variable instead of its use
Fixes#1996: [wgsl-in] Confusing error: "expected unsigned/signed integer literal, found '1'"
Separate parsing from lowering by generating an AST, which desugars as
much as possible down to something like Naga IR. The AST is then used
to resolve identifiers while lowering to Naga IR.
Co-authored-by: Teodor Tanasoaia <28601907+teoxoy@users.noreply.github.com>
Co-authored-by: Jim Blandy <jimb@red-bean.com>
When lowering `Select` expressions the position could be wrongfully
updated from `AccessBase { constant_index: false }` to
`AccessBase { constant_index: true }` this caused dynamic indexing
in an array behind a structure to fail if it was stored in a constant.
Furthermore the position could also be updated from `Rhs` to
`AccessBase`, this could cause issues because `AccessBase` doesn't
load variables (which `Rhs` does), so accessing a member from a
structure behind a pointer would return the wrong result.
* refactor: satisfy `clippy::borrow_deref_ref`
* chore: satisfy `clippy::ptr_arg`
* refactor: satisfy `clippy::needless_update`
* chore: `allow(clippy::too_many_arguments)` on `write_output_glsl` test
Since this is test code, I don't think there's a strong impetus to refactor types to consolidate
or otherwise alter arguments here. Let's just `allow` this.
* refactor: satisfy `clippy::single_match`
I think it's sixes whether to keep this code as-is or to `allow(...)` as-is. 🤷🏻♂️
* refactor: satisfy `clippy::single_char_pattern`
* refactor: satisfy `clippy::reversed_empty_ranges`
The lint fires because it generally doesn't make sense to use a `Range` built this way; [upstream
`Range` docs]) states:
> It is empty if `start >= end`.
`clippy` wants to help us from naively iterating over a `Range` like this! Thanks, `clippy`!
However, we're not actually using the offending `addresses` variables for iteration. We're using
them as a flat data structure with fields that happen to conceptually match. We can, therefore,
sidestep this lint by "just" inlining into separate variables for start and end instead.
[upstream `Range` docs]: https://doc.rust-lang.org/stable/std/ops/struct.Range.html
* refactor: satisfy `clippy::pattern_type_mismatch`
* chore: `allow(clippy::panic)` for `test`
We definitely should let `panic!(...)` calls exist in `cfg(test)`! It's a very standard way to fail
`#[test]` functions. It seems that previous test authors agree! 😅
* fixup! refactor: satisfy `clippy::pattern_type_mismatch`
* fixup! refactor: satisfy `clippy::single_match`
Previously when parsing an initializer list, the type passed to
`parse_initializer` was not updated to reflect the child type, this
caused implicit conversions to not work and nested initializer lists to
not be allowed.
When it was introduced it was supposed to allow for fast compiles by
skipping glsl specific validation, but as it turns the subset of glsl that's
compilable code is already pretty close to the subset of valid glsl code.
So the current code gated behind glsl-validate amounts to a single branch that
isn't even performance sensitive, and most of the validation is not specific to
glsl and is made by naga's validator which can be turned off, so the original
goal of fast compile times by disabling validation can still be accomplished.
Previously, if a local variable was declared with a constant value, we
would elide the store and instead give the variable an initial value (as
if it was a global variable). This caused variables to not be
re-initialized each time through a loop.
Adds parsing support for methods on the glsl frontend, while `.length` is the only method in the base extensions, there might be more in extensions.
Adds support for the `.length` method and tests for it.
