On old Cargo.lock, cannot compile kas-wgpu due to 2 versions of raw-window-handle

[nyanpasu64]

On an older Cargo.lock, when I try building master 0c6b51f on rustc 1.57.0 (f1edd0429 2021-11-29), I get an error:

Build output

error[E0277]: the trait bound `winit::window::Window: raw_window_handle::HasRawWindowHandle` is not satisfied
  --> crates/kas-wgpu/src/shared.rs:91:38
   |
91 |             match Clipboard::connect(_window) {
   |                   ------------------ ^^^^^^^ the trait `raw_window_handle::HasRawWindowHandle` is not implemented for `winit::window::Window`
   |                   |
   |                   required by a bound introduced by this call
   |
help: trait impl with same name found
  --> /home/nyanpasu64/.cargo/registry/src/github.com-1ecc6299db9ec823/raw-window-handle-0.4.2/src/lib.rs:58:1
   |
58 | / unsafe impl<'a, T: HasRawWindowHandle + ?Sized> HasRawWindowHandle for &'a T {
59 | |     fn raw_window_handle(&self) -> RawWindowHandle {
60 | |         (*self).raw_window_handle()
61 | |     }
62 | | }
   | |_^
   = note: perhaps two different versions of crate `raw_window_handle` are being used?
note: required by a bound in `Clipboard::connect`
  --> /home/nyanpasu64/.cargo/registry/src/github.com-1ecc6299db9ec823/window_clipboard-0.2.1/src/lib.rs:37:23
   |
37 |     pub fn connect<W: HasRawWindowHandle>(
   |                       ^^^^^^^^^^^^^^^^^^ required by this bound in `Clipboard::connect`

error[E0277]: the trait bound `winit::window::Window: raw_window_handle::HasRawWindowHandle` is not satisfied
  --> crates/kas-wgpu/src/window.rs:88:63
   |
88 |         let surface = unsafe { shared.instance.create_surface(&window) };
   |                                                -------------- ^^^^^^^ the trait `raw_window_handle::HasRawWindowHandle` is not implemented for `winit::window::Window`
   |                                                |
   |                                                required by a bound introduced by this call
   |
help: trait impl with same name found
  --> /home/nyanpasu64/.cargo/registry/src/github.com-1ecc6299db9ec823/raw-window-handle-0.4.2/src/lib.rs:58:1
   |
58 | / unsafe impl<'a, T: HasRawWindowHandle + ?Sized> HasRawWindowHandle for &'a T {
59 | |     fn raw_window_handle(&self) -> RawWindowHandle {
60 | |         (*self).raw_window_handle()
61 | |     }
62 | | }
   | |_^
   = note: perhaps two different versions of crate `raw_window_handle` are being used?

For more information about this error, try `rustc --explain E0277`.
error: could not compile `kas-wgpu` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed

cargo tree shows that winit v0.26.0 uses raw-window-handle v0.4.2, while wgpu v0.11.1 (and other libraries?) uses raw-window-handle v0.3.3.

Deleting Cargo.lock fixed this issue, but I kinda feel it's a bug in Cargo.toml for KAS to depend on multiple libraries using the same raw-window-handle version, but not actually enforce it. Is this resolvable, or impossible due to Cargo limitations? Do you plan to address this or not?

Seems there's some related discussion at rust-lang/cargo#8178 and rust-lang/rust#44663 (but unresolved).

[dhardy]

raw-window-handle v0.3.4 is a compatibility shim, which I've had the dis-pleasure of releasing in the past (rand_core). They cannot make everyone happy.

From the perspective of KAS (as a downstream crate), we could fix this by adding a dependency on raw-window-handle v0.3.4 until WGPU is updated.

We could also detect this type of issue via CI with cargo generate-lockfile -Z minimal-versions (see e.g. rand workflow).

Want to make a PR?

[nyanpasu64]

It seems kas-core has an optional winit dependency. Is it even possible to add an optional raw-window-handle dependency tied to another optional crate which becomes a feature? (I think this isn't possible in stable Rust, link)

I wish optional crates didn't implicitly become features (which IIRC is the case now, link), and you instead explicitly defined the exact set of public features available, which map to optional dependencies and their features. This implicit behavior feels "wrong", much like the implicit behavior of use Trait magically materializing extension methods on unrelated types, making a use Trait statement look unused when there's no other textual occurrences of Trait in the entire source file, only method calls enabled by having the trait in scope.

Also I tried running cargo +nightly generate-lockfile -Z minimal-versions, but this produced some particularly spectacular errors when I ran cargo check (log at minver-error.txt).

[dhardy]

I think weak dependency features are what is actually wanted. In any case, it doesn't matter here because kas-wgpu (non-optionally) depends on both winit and wgpu.

I wish optional crates didn't implicitly become features

Agreed. You can kind of get around this by renaming dependencies but it's a pain, and requires caution when adding optional dependencies.

much like the implicit behavior of use Trait magically materializing extension methods on unrelated types

While the non-obvious method resolution is annoying, this is a very useful feature, and much less insidious behaviour than in is common in languages like C/C++. Using NameExt naming convention can help. Anyway, off topic.

but this produced some particularly spectacular errors

Yup, probably several crates would need the minimum patch version bumping. Possibly also in dependencies, since many crates don't bother declaring correct minimum versions (which again, can be "fixed" via extra dependencies within this library, but is annoying to do). I've lost track of how many times I've told people "just do cargo update", but that really is the simplest solution.

[nyanpasu64]

Shrug. Does cargo check/build automatically alter the lockfile to match updated Cargo.toml without running cargo update? Does the proposed PR fix people running kas-gui for examples, or third-party apps using it? I'm not sure I can even test any proposed fix I make, since I deleted my raw-window-handle 0.3.3 Cargo.lock, and regenerating a lockfile with minimal-versions produces an unusable lockfile.

When testing a potential PR, I tried editing crates/kas-wgpu/Cargo.toml to include raw-window-handle = "=0.3.3" and ran cargo update to reproduce this bug. then replaced it with raw-window-handle = "0.3.4" seems to fix the bug when running cargo check without update. Is adding this extra dependency a good idea, or does it make kas-wgpu too brittle and requires removing the redundant dependency (wasted compile times) once wgpu updates to 0.4?

Ideally there would be some syntax for "if you use raw-window-handle 0.3, it must be 0.3.4" syntax (and you know 0.3.3 is wrong since you depend on winit 0.26.0 which requires raw-window-handle 0.4.x).

(I do wonder if there's some principled solver-level fix for ensuring that two libraries depend on compatible raw-window-handle versions, where 0.3.4 is compatible in some sense with 0.4.x (uses the same traits? structs?). I suspect it's too complex to make it work in a reasonable time, or 100% accurately (I don't fully understand the problem). https://github.com/rust-windowing/raw-window-handle/blob/master/CHANGELOG.md, https://github.com/rust-windowing/winit/blob/master/CHANGELOG.md#0260-2021-12-01 tells you to run cargo update -p raw-window-handle, hmm.)

Dependency resolution just feels highly nonlocal and hard to understand, and this makes me sad because Rust is built around enabling local reasoning.

[dhardy]

Does cargo check/build automatically alter the lockfile to match updated Cargo.toml without running cargo update?

To match requirements, yes. E.g. if after the repo is updated, there is a dependency on crate X v0.2.3 but there is an existing dependency on X v0.2.2, then this is updated. If an update to Y is available but nothing depends on a newer version than is already in the lockfile, then it won't be updated without cargo update or similar.

Does the proposed PR fix people running kas-gui for examples, or third-party apps using it?

Both.

regenerating a lockfile with minimal-versions produces an unusable lockfile

The idea is to fix this via whatever version-bumps are needed.

Is adding this extra dependency [to kas-wgpu] a good idea

It should be removed when WGPU is updated. It shouldn't break anything (even if it's not removed, then it's just an unneeded dependency).

Ideally there would be some syntax for "if you use raw-window-handle 0.3, it must be 0.3.4" syntax

I don't think this is viable. There are basically two paths:

• Yank raw-window-handle v0.3.x < 0.3.4. This prevents people who want to test builds with older version from doing so, and doesn't actually fix anything since yanked versions still aren't automatically updated. Maybe Cargo could fix the latter part, but this still seems unwanted.
• Some new Cargo feature to allow raw-window-handle to declare it should always be updated to the latest patch version. This also prevents people from testing old versions (and causing major annoyance should a broken patch be released).

Perhaps there is a workable fix within Cargo actually (roughly what you suggested):

• Have Cargo detect when some downstream crate is depended on in multiple incompatible versions (raw-window-handle v0.3 and v0.4) where also there is a compatibility shim (v0.3.x which depends on v0.4) and then recommend that the downstream crate add an additional dependency (as suggested above for kas-wgpu) to resolve the issue. Note that even in this case it is still not a good idea to have Cargo force the update; e.g. a compatibility shim may be published later and may break something.

But really I think we should just accept that this is never going to be perfect.

[nyanpasu64]

I don't think this is viable. There are basically two paths:

I didn't mean raw-window-handle should declare 0.3.4 is a blessed version. I meant I wanted kas-gui (which is using winit 0.26 and raw-window-handle 0.4) to declare that raw-window-handle 0.3.x is prohibited except from 0.3.4 (much like how Cargo prohibits including multiple 0.4.x versions of any crate).

Also is the PR actually important? I hit the version conflict by git pulling the kas-gui repo itself (which has no committed Cargo.lock), but I think most people including the kas-gui library will only update to newer kas-gui (which includes winit 0.26 and raw-window-handle 0.4) when running cargo update (which pulls in raw-window-handle 0.3.4 along the way). So my version conflict is actually a rare case, and I probably should've run cargo update anyway (or you could've committed a Cargo.lock which isn't distributed as part of the library, and kept it up to date for KAS development). And I think the PR isn't necessary for library users in the wild. Or did I miss something or misjudge?

[dhardy]

Adding a dependency on 0.3.4 achieves that.

The other case this could happen is when someone is when working on a dependency using kas and bumps the version.