Open Bug 1804530 Opened 2 years ago Updated 8 months ago

`wgpu` imports broken because `cargo vendor` can't handle workspace inheritance

Categories

(Core :: Graphics: WebGPU, task, P1)

task

Tracking

()

People

(Reporter: jimb, Unassigned)

Details

This cargo vendor bug is blocking our wgpu imports: https://github.com/rust-lang/cargo/issues/11192

Using mach vendor rust to bring in git dependencies, like those used in gfx/wgpu_bindings/Cargo.toml, produces broken crate sources in third_party/rust.

wgpu uses Cargo workspace inheritance to avoid reiterating the same values over and over in every crate's Cargo.toml file, but cargo vendor (used by mach vendor rust) splits workspaces into individual crates. For crates published on crates.io, cargo vendor takes advantage of the fact that cargo publish already handles rewriting the Cargo.toml files to be independent of their workspace, but for git dependencies - picking a specific commit out of a git repository - cargo vendor seems to just copy the crate's subtree out of the workspace without fixing up its Cargo.toml file. This gives a crate that doesn't build, because its Cargo.toml file has stuff like this:

[package]
name = "wgpu-core"
version.workspace = true
authors.workspace = true
edition.workspace = true
description = "WebGPU core logic on wgpu-hal"
homepage.workspace = true
repository.workspace = true
keywords.workspace = true
...

which doesn't fly.

From the https://github.com/rust-lang/cargo/issues/11192#issuecomment-1272364357:

In the meanwhile, we are seeking help for polishing the error message. Something explicitly tells user the cause is great, such like "vendoring a git dependency with inherited fields from a workspace is not supported yet".

Landed workaround upstream: https://github.com/gfx-rs/wgpu/pull/3295

Since there's a workaround landed upstream, kicking this out of webgpu-in-nightly's blockers.

I don't think it needs to block anything else.

No longer blocks: webgpu-in-nightly

rust-lang/cargo#11192 has landed, so this may be fixed.

Once the fix is available in a stable cargo, we can close this Bugzilla bug.

The fix for this bug shipped in Cargo 1.68. Since Firefox 115's MSRV is still 1.66, I think we should leave this open.

Firefox's MSRV is still 1.66.

No longer blocks: webgpu-triage
You need to log in before you can comment on or make changes to this bug.