mirror of
https://github.com/gfx-rs/wgpu.git
synced 2024-12-02 03:33:35 +00:00
21c7092762
* 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` |
||
|---|---|---|
| .. | ||
| in | ||
| out | ||
| snapshots.rs | ||
| spirv-capabilities.rs | ||
| wgsl-errors.rs | ||