Add `HandleSet` methods `new`, `clear`, `clear_for_arena`, and
`remove`.
Change the type of `naga::valid::Validator::valid_expression_set` from
`BitSet` to `HandleSet`. Adjust uses.
Change `HandleSet::insert` to return `true` if the handle was not
already in the set.
Change uses in `naga::compact` which were taking advantage of the
prior return type of `()` to avoid needing to use semicolons in
`match` arms.
Change `naga::proc::index::find_checked_indexes` to return a
`HandleSet<Expression>`, rather than an untyped `BitSet`.
Fix uses in the Metal Shading Language backend.
Change the `std::fmt::Debug` impl for `naga::arena::Range` to print a
start-inclusive, end-exclusive range.
- This is more consistent with Rust's `std::ops::Range`.
- This is consistent with the serialization form used in snapshots,
which simply uses the serialization of `std::ops::Range`.
- It is not consistent with Naga's constructor function
`Range::new_from_bounds`, which takes an inclusive end value, or
with `Range::first_and_last`, which returns an inclusive end value.
Both of these need to represent ranges' end points as `Handle`s, but
exclusive end values might not be valid `Handle` values. I think
this divergence is tolerable.
This commit is almost entirely code motion. The only meaningful
changes should be:
- changes to imports
- changes to visibility
- changes to use visible associated constructor functions instead of
trying to construct values directly using now-invisible fields
- moving the crate-level "Arena" docs into the `arena` module
In preparation for making `Handle` fields private to another module,
have the `Iterator` implementation for `arena::Range` call
`Handle::new` to construct the handle being produced, rather than
building it using a struct literal.
Use the associated function `Range::from_index_range` to construct the
return value of `Arena::range_from`, rather than constructing the
`Range` directly, in preparation for those fields becoming private.
We are using `program_cache.try_lock()` when creting pipelines which is covered by a guard gotten from `context.lock()`. For the `.try_lock()` to always succeed we need to make sure that the other lock acquisitions are also covered by a `context.lock()`.
The `wgpu_examples::hello_compute::tests::multithreaded_compute` test has been failing intermittently in CI due to this.
* Add an optional system for counting and reporting internal resources and events
* Count API objects in wgpu-hal
* Expose internal counters in wgpu-core and wgpu.