Update most significant versions of direct dependencies

[nazar-pc]

I didn't touch most of the dependencies, only those that didn't have the latest most significant version, which results in downstream users having a lot of duplicate packages.

I removed clap constraint since I believe it was related to older toolchain used in this repo, which has been upgraded and should no longer be a problem.

Checked all changelogs available and didn't find anything problematic there.

[nazar-pc]

Getting this, not sure what to do about it though:

error: cannot offset a pointer to an arbitrary element
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:143:1
    |
143 | / bitflags::bitflags! {
144 | |     /// Flags controlling the properties of an OpTraceRayKHR instruction.
145 | |     /// Despite being a mask and allowing multiple bits to be combined, it is
146 | |     /// invalid for more than one of these four bits to be set: `OPAQUE`,
...   |
176 | | }
    | |_^
    |
note: used from within `<spirv_std::ray_tracing::_::InternalBitFlags>::all`
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:143:1
    |
143 | / bitflags::bitflags! {
144 | |     /// Flags controlling the properties of an OpTraceRayKHR instruction.
145 | |     /// Despite being a mask and allowing multiple bits to be combined, it is
146 | |     /// invalid for more than one of these four bits to be set: `OPAQUE`,
...   |
176 | | }
    | |_^
note: called by `<spirv_std::ray_tracing::_::InternalBitFlags>::from_bits_truncate`
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:143:1
    |
143 | / bitflags::bitflags! {
144 | |     /// Flags controlling the properties of an OpTraceRayKHR instruction.
145 | |     /// Despite being a mask and allowing multiple bits to be combined, it is
146 | |     /// invalid for more than one of these four bits to be set: `OPAQUE`,
...   |
176 | | }
    | |_^
note: called by `<spirv_std::ray_tracing::RayFlags>::from_bits_truncate`
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:143:1
    |
143 | / bitflags::bitflags! {
144 | |     /// Flags controlling the properties of an OpTraceRayKHR instruction.
145 | |     /// Despite being a mask and allowing multiple bits to be combined, it is
146 | |     /// invalid for more than one of these four bits to be set: `OPAQUE`,
...   |
176 | | }
    | |_^
note: called by `<spirv_std::ray_tracing::RayQuery>::get_ray_flags`
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:425:13
    |
425 |             RayFlags::from_bits_truncate(result)
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: called by `ray_query_get_ray_flags_khr::main`
   --> $DIR/ray_query_get_ray_flags_khr.rs:13:28
    |
13  |         let flags = handle.get_ray_flags();
    |                            ^^^^^^^^^^^^^^^
note: called by `main`
   --> $DIR/ray_query_get_ray_flags_khr.rs:9:8
    |
9   | pub fn main(#[spirv(descriptor_set = 0, binding = 0)] accel: &AccelerationStructure) {
    |        ^^^^

error: const_bitcast
    |
note: used from within `<spirv_std::ray_tracing::_::InternalBitFlags>::all`
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:143:1
    |
143 | / bitflags::bitflags! {
144 | |     /// Flags controlling the properties of an OpTraceRayKHR instruction.
145 | |     /// Despite being a mask and allowing multiple bits to be combined, it is
146 | |     /// invalid for more than one of these four bits to be set: `OPAQUE`,
...   |
176 | | }
    | |_^
note: called by `<spirv_std::ray_tracing::_::InternalBitFlags>::from_bits_truncate`
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:143:1
    |
143 | / bitflags::bitflags! {
144 | |     /// Flags controlling the properties of an OpTraceRayKHR instruction.
145 | |     /// Despite being a mask and allowing multiple bits to be combined, it is
146 | |     /// invalid for more than one of these four bits to be set: `OPAQUE`,
...   |
176 | | }
    | |_^
note: called by `<spirv_std::ray_tracing::RayFlags>::from_bits_truncate`
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:143:1
    |
143 | / bitflags::bitflags! {
144 | |     /// Flags controlling the properties of an OpTraceRayKHR instruction.
145 | |     /// Despite being a mask and allowing multiple bits to be combined, it is
146 | |     /// invalid for more than one of these four bits to be set: `OPAQUE`,
...   |
176 | | }
    | |_^
note: called by `<spirv_std::ray_tracing::RayQuery>::get_ray_flags`
   --> rust-gpu/crates/spirv-std/src/ray_tracing.rs:425:13
    |
425 |             RayFlags::from_bits_truncate(result)
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: called by `ray_query_get_ray_flags_khr::main`
   --> $DIR/ray_query_get_ray_flags_khr.rs:13:28
    |
13  |         let flags = handle.get_ray_flags();
    |                            ^^^^^^^^^^^^^^^
note: called by `main`
   --> $DIR/ray_query_get_ray_flags_khr.rs:9:8
    |
9   | pub fn main(#[spirv(descriptor_set = 0, binding = 0)] accel: &AccelerationStructure) {
    |        ^^^^

error: aborting due to 2 previous errors

cargo-deny seems more annoying than useful BTW.

[Firestar99]

For some reason, our backend doesn't like the following expression which bitflags 2.X expands to. I downgraded it back to 1.X for now. @eddyb any ideas?

error: cannot offset a pointer to an arbitrary element
    --> /home/firestar99/workspace/rust-gpu/crates/spirv-std/src/ray_tracing.rs:675:28
     |
675  |                 let flag = <RayFlags as bitflags::Flags>::FLAGS[i].value().bits();
     |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |

[Firestar99]

About cargo-deny: it's mostly been inherited from Embark (which also maintain cargo-deny) and we just kept on using it. I do see how it is annoying, and I wonder if we should limit it to public facing crates instead of everything. @LegNeato thoughts?

[nazar-pc]

It mostly complains about things like multiple versions of Windows crate that is basically a fault of the way Microsoft packages it and there is essentially nothing that can be done about it. You just suppress it when cargo-deny complains and remove suppression when it does not. Not really actionable in any other way.

[nazar-pc]

I updated deny.toml to allow duplicate packages, avoiding maintaining a growing list of exceptions for no good reason.

[LegNeato]

It is actionable, in the past I have sent PRs to the deps to upgrade versions to fix the errors. It takes time though, and not sure it is super worth it.

On my phone, but curious about the build times with vs without

[Firestar99]

I tried to just exclude the examples from duplicate detection, so that at least our public dependencies are checked, but I can't seem to get it to work. I'd merge this as-is and reenable duplicate detection if we can figure out how to do this properly.
CI times seems to have changed sightly, but seem too variable to tell.
EmbarkStudios/cargo-deny#783