This is for the same reason that we ignore `dead_code`:
// A lot of the code can be unused based on configuration flags,
// the corresponding warnings aren't helpful.
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.
* fix(glsl-out,hlsl-out,msl-out): parenthesize unary negations a la `wgsl` everywhere
Unify parenthesization of unary negations across all backends with what the `wgsl` backend does,
which is `<op>(<expr>)`. This avoids ambiguity with output languages for which `--` is a different
operation; in this case, we've been accidentally emitting prefix decrements.
* build: update `rspirv` 0.11 -> 0.12 (FIXME: use upstream release)
* test: add `operators::negation_avoids_prefix_decrement` test
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
* 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`
* build: move to the Rust 2021 edition
Since the MSRV of `naga` [is currently 1.56][msrv], I don't think there's a strong reason to stay
with the 2018 edition, and there _are_ a [few good reasons][edition-guide] to move to the 2021
edition.
I did this migration mostly automatically, per [official Rust guidelines]:
```sh
$ cargo fix --edition --all-targets
$ sed -i Cargo.toml 's/2018/2021'
$ cargo fix --edition-idioms --allow-dirty # doesn't change anything
```
The only manual edit needed to stymie a new warning introduced was the removal of the `TryFrom`
import in several modules, since it's now in the 2021 prelude.
[msrv]: a7193d652e/.github/workflows/pipeline.yml (L14)
[edition-guide]: https://doc.rust-lang.org/edition-guide/rust-2021/index.html
[official Rust guidelines]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html#edition-migration
* refactor(wgsl-in): use `pat` instead of `pat_param` again
How we were using `pat` in the Rust 2018 edition is actually the use case that
Rust 2021's `pat` fragment specifier is intended to satisfy. So, let's just use
that!
* Fix incorrect atomic bounds check on metal back-end
Generalize put_atomic_fetch to handle `exchange` as well, rather than special-cased code which didn't do the bounds check (the check handling as fixed in #1703 but only for the fetch cases, exchange was skipped).
Fixes#1848
* Add tests for atomic exchange
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.
Whitespace and formatting changes only.
It turns out that if `cargo fmt` comes across a single line it can't
make fit within the margins, then it sort of gives up on the
surrounding construct. So breaking up the error message for
`Error::UnknownScalarType` in `Error::as_parse_error` and then
re-running `cargo fmt` cleans up lots of other stuff in the file.
cargo fmt issue:
https://github.com/rust-lang/rustfmt/issues/3863
The wgsl frontend was emiting errors for lhs expressions on assignments
that weren't references using a span that didn't skip blankspaces
causing the span to look weird (like starting at the end of the previous
line)
This is fixed by consuming the blankspace before constructing the span
