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`.
In Clippy 1.67, the `needless_borrowed_reference` lint [was enhanced]
to look into struct and tuple patterns, so that a line like this:
for &(ref module, ref info) in inputs.iter()
where `inputs.iter()` is yielding `&(Module, ModuleInfo)` pairs,
elicits a warning. Clippy suggests, instead:
for (module, info) in inputs.iter()
but this is at odds with Naga's preference that `match` patterns
should have the same type as the expression being matched, for which
we have enabled the `pattern_type_mismatch` lint since
9e5cc4c9 (2021-3-12).
[was enhanced]: https://github.com/rust-lang/rust-clippy/pull/9855
* 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`
* Make some (currently hacky) changes to enable multiview in webgl
* Fix ViewIndex built in for this extension
* Run cargo fmt, fix tests
* Allow specifying if we're targetting webgl in the glsl version
* Document multiview2 extension
* fn embedded -> const fn embedded
* Fix tests
* Fix benches
* Add snapshot tests
* Revamp so that the glsl options have some multiview options. Also add tests
* Make clippy happier
* Go back to having is_webgl be part of Version
* Use wgsl as input for tests
* Rename Version::new_embedded to Version::new_gles, fix glsl validation
* Run cargo fmt
* Fix brand new clippy warnings
