Yank versions of wgpu without #5812?

[workingjubilee]

Before d309bba, Direct3D was just merrily reading random uninit data into its execution. We know this for a fact because the very moment wgpu called a version of compile_fxc compiled by a rustc with rust-lang/rust@38104f3 on Windows, the programs got hoist on the petard of STATUS_ACCESS_VIOLATION. Much better, because the bug was made visible and has been quickly fixed! It is worth considering yanking affected versions of wgpu, especially those that have the fix backported to their major version, so that Windows stops munching on garbage data, and to accelerate retiring the affected versions from the ecosystem (even if it does not actually completely remove them due to how yanking works).

...Or not! I'm a programmer, not a cop.

[ErichDonGubler]

Adding this to our wgpu maintainers meeting agenda for next Wednesday.

[jimblandy]

Which versions are affected?

[workingjubilee]

This goes back to the introduction of 81569dd sooo wgpu 0.15.0 it seems?

That is a... lot of versions to yank, so I think it would be most productive to, e.g.

• yank wgpu 0.20.0 and 0.20.1, since the patch is in 0.20.2 and that would force the upgrade (thus, having an actual practical effect)
• decide on a disposition for Backport Do not feed &"" to D3DCompile (#5812) to 0.19 #5833
• consider yanking previous 0.19 versions if the answer is "merge"
• decide on a disposition for Backport Do not feed &"" to D3DCompile (#5812) to 0.18 #5834
• consider yanking previous 0.18 versions if the answer is "merge"
• only then consider 0.17, 0.16, and 0.15

[ErichDonGubler]

Bringing back in the consensus from the 2024-06-26 maintainers meeting: we intend to yank all affected release versions. We will provide patch releases for 0.19.* and 0.18.*, since the community has already shown interest, and backport PRs are open. If others want to take the time to backport for older (yanked) releases, we will consider on a case-by-case basis.

_{EDIT: Shared the above in Matrix for users and maintainers.}

[ErichDonGubler]

We have yanked the 0.20 and 0.21 series of wgpu-hal and wgpu-core, minus the latest 0.21.* release. We have also yanked the 0.20.0 release of wgpu in favor of the 0.20.1 release, which can optionally upgrade to the 0.21.1 release of wgpu-hal and wgpu-core.

I will be taking further time to merge v0.19 and v0.18 branch updates and post respective updates next week, after which previous releases in those minor version tracks with be yanked.

[ErichDonGubler]

The 0.19.* series has been updated and yanked, with CHANGELOG entries backported to trunk:

Will tackle 0.18.* tomorrow.

[mlafeldt]

Do you know that yanking those crates broke all versions of Deno except for the current one (1.45), released last week?

❯ cargo update
...
error: failed to select a version for the requirement `wgpu-core = "^0.20"`
candidate versions found which didn't match: 0.21.1, 0.19.4, 0.19.3, ...
location searched: crates.io index
required by package `deno_webgpu v0.125.0`
    ... which satisfies dependency `deno_webgpu = "^0.125.0"` of package `deno_runtime v0.166.0`
...

Update: The yanking affects all Deno releases of 1.43 and 1.44, reaching back to May 1.

[mlafeldt]

Hotfix for people using Deno 1.44:

[workspace.dependencies]
# Deno v1.44.4
deno_core = "=0.290.0"
deno_runtime = "=0.166.0"

[patch.crates-io]
wgpu-core = { git = "https://github.com/gfx-rs/wgpu", tag = "v0.20.0" }
wgpu-types = { git = "https://github.com/gfx-rs/wgpu", tag = "v0.20.0" }

[ErichDonGubler]

@mlafeldt: That breakage implies a build attempting to either create a lockfile from scratch, or update a lockfile's wgpu* dependencies. Projects with an existing Cargo.lock that aligns with existing Cargo manifests should continue to build as before.

Will summon @crowlKats here specifically on the topic of Deno support and/or help understanding where Deno integration will go from here.