[d3d12 wgl] Upgrade to windows 0.62 crates

[MarijnS95]

Connections

https://github.com/microsoft/windows-rs/releases/tag/0.61.0
https://github.com/microsoft/windows-rs/releases/tag/63
https://github.com/microsoft/windows-rs/releases/tag/69

Description

Uses the latest windows 0.62 and windows-core 0.62 releases, including some minor code improvements for us. The MSRV has been bumped to 1.74, but wgpu is already on 1.76 anyway.

Testing

WGPU_BACKEND=d3d12 cargo r -p wgpu-examples hello_triangle

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.
• Replaced crate patches with actual releases.

[MarijnS95]

@kennykerr can you help us here? I did not do my due diligence this time to search through windows-rs and win32metadata for relevant changes, but while most handles have been made optional (see other Some() wrapping changes in this PR), quite strangely these parameters are no longer optional in wglMakeCurrent() where they have a specific use-case to uncurrent the context.

Is this change intended or accidental? We can clearly get around it by passing a defaulted HDC/HGLRC, but it seems strange when compared to other functions where None can be passed.

[kennykerr]

The code generator now faithfully honors the metadata's [Optional] attribute - in the case of wglMakeCurrent the handle parameters are not optional whereas in the case of CreateSwapChainForCompositionSurfaceHandle the handle parameter is optional.

[MarijnS95]

Thanks @kennykerr. So this'll take another trip through win32metadata to annotate correctly.

[cwfitzgerald]

Just to set expectations here, we likely can't merge this for a bit, as firefox is currently on 0.58 and migration will be a bit of a thing. @ErichDonGubler will take charge of this.

I don't expect there to be a ton of problems with this PR just hanging out for a while. I'm going to mark this as draft as we can't merge it, but @Wumpf will review it still.

[MarijnS95]

@cwfitzgerald that's all good, I don't expect this to be merged until the upgrade has fully trickled through the ecosystem. Just making sure we have a PR open with all the necessary changes that I couldn't make in the original windows-rs migration due to missing or incorrect upstream annotations.

[ErichDonGubler]

There are a few things that I'm already aware need to happen in mozilla-central before this can land:

• Dependencies on windows
  • Bump gpu-allocator after a version releases that consumes cargo: Bump windows crate range to 0.53-0.59 Traverse-Research/gpu-allocator#258.
    • We might need this backported to 0.27.0, since mainline upstream now uses objc2-metal, which we're blocked on moving to because of [metal] Use objc2-metal #5641 (CC @Jasper-Bekkers, @MarijnS95).
  • mtu migrated from windows-{bindgen,core} and windows-targets to windows >=0.58.0,<0.60.0: Move to windows 0.58.0, and also permit version 0.59 mozilla/mtu#65
• Dependencies on windows-sys
  • mio: build: update windows-sys to 0.59.0 tokio-rs/mio#1857
  • Coordinate upgrades with folks working on neqo: Allow downstreams to upgrade to Windows 0.59 mozilla/neqo#2662
  • audio_thread_priority needs migration: build: upgrade windows-sys 0.52 → 0.59 mozilla/audio_thread_priority#30
  • tempfile can have its version range extended: build: allow windows-sys 0.59 Stebalien/tempfile#319 Actually already works, but it has a nitpick issue with its range specification.
  • socket2 can have its version range extended:
    • build: allow windows-sys 0.59 rust-lang/socket2#545
    • Update to Windows-sys v0.59 rust-lang/socket2#579
  • tokio needs migration: build: upgrade windows-sys 0.52 → 0.59 tokio-rs/tokio#7117
    • is-terminal can have its version range extended: build: allow windows-sys 0.59 sunfishcode/is-terminal#43
• Direct dependencies on windows-targets
  • libloading can widen its accepted ranges of windows-targets to include 0.53.*: build: allow windows-core 0.59, windows-targets 0.53 nagisa/rust_libloading#169
  • backtrace: consume a new libloading and update workspace: build(core): allow windows-targets 0.53.0 rust-lang/backtrace-rs#694
  • parking_lot_core: consume a new backtrace and update workspace: build(core): allow windows-targets 0.53.0 Amanieu/parking_lot#458

[larseggert]

Regarding neqo and mtu, we can bump whenever you're ready - just let us know. (CC @mxinden for info).

[mxinden]

Regarding neqo and mtu, we can bump whenever you're ready - just let us know. (CC @mxinden for info).

Under the assumption that windows v0.59 does not introduce a breaking change for neqo or mtu, we can also make neqo and mtu compatible to both windows v0.58 and v0.59 by configuring a range:

windows-sys = { version = ">=0.58, <=0.59"

See quinn-rs/quinn#2021 as an example from one of our upstream dependencies.

@ErichDonGubler let me know what works best for you.

[Wumpf]

fwiw code lgtm and took it on a spin running examples locally

[MarijnS95]

• Bump gpu-allocator after a version releases that consumes cargo: Bump windows crate range to 0.53-0.59 Traverse-Research/gpu-allocator#258.

  • We might need this backported to 0.27.0, since mainline upstream now uses objc2-metal, which we're blocked on moving to because of [metal] Use objc2-metal #5641 (CC @Jasper-Bekkers, @MarijnS95).

@ErichDonGubler I think we can arrange this pretty quickly, let us know when the time is there (and you haven't yet upgraded to objc2-metal by then).

[MarijnS95]

Sorry I completely dropped the ball on this and there are quite a few new versions already. I'll get back to the second bump ASAP, as long as Mozilla is okay with the next bumps?

[ErichDonGubler]

@MarijnS95: The way to keep this tractable is almost certainly to keep uograde steps incremental, so don't feel like you need to throw away efforts to target 0.59 without a strong concrete blocker.

[MarijnS95]

We dropped gpu-allocator 0.28 :)

[ErichDonGubler]

@MarijnS95:

I think we might benefit from retrying with the latest windows crate ecosystem, rather than trying to continue with 0.59.

@ErichDonGubler with that, are you referring to 0.61 from #8013 or the latest 0.62 release which barely misses out on range compatibility due to #8013 (comment)?

I'm referring to 0.62, sorry for any confusion!

Much of the ecosystem has caught up with 0.62, with some refusing to use range dependencies. I've also confirmed that we can build it in Firefox, done all the auditing work for new dependencies. The main supply chain task is some upstreaming before review that can be done incrementally per-dependency (see Bug 1991226 - Upgrade/audit most Rust deps. for WGPU revendor and windows 0.62, part 1).

I'll let you judge for yourself, though. I've put a PR for 0.62 up—based on work here—for your perusal: #8281

[MarijnS95]

Much of the ecosystem has caught up with 0.62, with some refusing to use range dependencies.

As already highlighted in #8013 (comment) three whole weeks ago wgpu itself cannot take a range dependency because of the Error::from_win32() -> Error::from_thread() rename.

I'll let you judge for yourself, though. I've put a PR for 0.62 up—based on work here—for your perusal: #8281

I thought I had also already shared https://github.com/MarijnS95/wgpu/compare/windows-69 with you those three weeks ago, and was merely waiting for confirmation to push it into this PR or #8013.

[MarijnS95]

Note that all these force-pushes to contributor PRs -in particular after such a long time of radio silence- seem a little disingenuous: I cannot even read the CI failure and git rebase --update-refs to amend the fixes into multiple PRs at once, before having git push --force-with-lease tell me that my remote branch changed since checkout? Would be awesome if you could ask next time whether help is needed 🙏

[ErichDonGubler]

As already highlighted in #8013 (comment) three whole weeks ago wgpu itself cannot take a range dependency because of the Error::from_win32() -> Error::from_thread() rename.

Sure, but that only means WGPU specifically suffers from being an all-or-nothing upgrade WRT this windows upgrade. It's still beneficial for WGPU's dependencies to be incrementally upgradeable, because incremental upgrades at Mozilla have a significantly lower risk of getting stuck. If you examine bug 1991226, that's exactly what I'm doing.

When you submitted that comment three weeks ago, this was, unfortunately, not something I could justify looking at (and I'm still not sure that I can drive this to completion, based on Mozilla's current priorities). I'm trying to split a bit of attention to take a look at this now, though, because I think it's important for Mozilla to have concrete reasons for either letting things through or being blocked, rather than "I don't got bandwidth indefinitely, soz."

[ErichDonGubler]

Note that all these force-pushes to contributor PRs -in particular after such a long time of radio silence- seem a little disingenuous: I cannot even read the CI failure and git rebase --update-refs to amend the fixes into multiple PRs at once, before having git push --force-with-lease tell me that my remote branch changed since checkout? Would be awesome if you could ask next time whether help is needed 🙏

Ah, sorry, I'm not trying to create obstacles for you! I'm happy to switch to appending fixup!s, or giving you diffs via PRs. Force-pushing generally works very well with less dedicated contributions, but you've been quite dedicated. ❤️ Happy to accommodate a better workflow here!

[ErichDonGubler]

I thought I had also already shared https://github.com/MarijnS95/wgpu/compare/windows-69 with you those three weeks ago, and was merely waiting for confirmation to push it into this PR or #8013.

I don't remember this being shared, but I think it's safe to say we've reached consensus for trying to target windows 0.62. I'm fine dismissing #8281, if you intend to reconcile it with #8013.

[MarijnS95]

I have yet to revert this back out. I added command-arguments: -Dwarnings to CI to catch some warnings that otherwise went unnoticed, but that includes unmatched allow-org when there are (temporarily) no patches from this org...

[MarijnS95]

Sure thing, having downstream dependencies commit to ranges (when possible) would be awesome and I've been trying to sneak them into crates whenever possible. Thus happen to contribute to quite a few too many, and it usually means preempting the maintainer or other contributors who are oblivious to this behavior (and getting the range extended backwards has thus far proven harder).

Hadn't looked at the Bugzilla tracker but it looks like a lot of crates to repeatedly vet; any way that could be reduced by less aggressively bumping patch versions where not necessary for e.g. this Windows upgrade?

Glad to see that you're at least trying to get something going here despite not finding time/priority. Apologies for the hasty response. Makes me fear the ever-increasing stack of PRs, issues and (mostly) complaints on popular repos that I'm supposed to be maintaining, ... 🤷

I'll happily keep #8013 up to date and rebased on this PR, and leave it to you whether to temporarily jump to 0.59 via this PR or go straight to 0.62. Since most context lives here, I can merge it into this PR too.

[ErichDonGubler]

I'd like to address this tension specifically, since I consider cultural gardening an important exercise:

Note that all these force-pushes to contributor PRs -in particular after such a long time of radio silence- seem a little disingenuous: ...

As I'm sure you know, being radio-silent generally isn't a problem for one-off contributions. This case is already different; IMO, you've definitely earned some negotiating power on how you'd like to communicate, given how much (welcome) work you've been doing. Thoughts? I'm guessing you would have preferred that we told you specifically that we knew we didn't have immediate bandwidth for windows upgrades. Alternatively, we don't mind getting pinged in issues like this if and when we do fail to communicate, though responsiveness can vary between Mozillians and from week to week. Sometimes, we have week-or-longer interruptions (like the recent WebGPU F2F, or Mozilla all-company meetings).

☝🏻 CC @gfx-rs/wgpu.

[ErichDonGubler]

Hadn't looked at the Bugzilla tracker but it looks like a lot of crates to repeatedly vet; any way that could be reduced by less aggressively bumping patch versions where not necessary for e.g. this Windows upgrade?

We tend not to repeatedly vet these crates, with the recent move in wgpu from Dependabot to Renovate. It was awful before that point.

Those specific dependencies are getting updated in that patches series because IIRC some other crate required a new minimum version on the road to getting upgraded to support `windows 0.62. I don't remember specifics for these, though...there were many. 😅

[ErichDonGubler]

RE: the set of PRs to keep open: I think consolidating everything into this PR would make things significantly easier to follow for everyone. We don't actually intend to land things incrementally, so multiple PRs sound only like additional complication.

[MarijnS95]

As I'm sure you know, being radio-silent generally isn't a problem for one-off contributions. This case is already different; IMO, you've definitely earned some negotiating power on how you'd like to communicate, given how much (welcome) work you've been doing. Thoughts? I'm guessing you would have preferred that we told you specifically that we knew we didn't have immediate bandwidth for windows upgrades.

This was mostly in respect to first being on one end of the spectrum (no response for weeks) to then jumping all the way to the other with force-pushes and respin PRs (something I tend to use sparingly when a contributor hasn't responded for weeks and I really want to get their change in after some minor CI/review fixups).

---

We tend not to repeatedly vet these crates, with the recent move in wgpu from Dependabot to Renovate. It was awful before that point.

Does that mean you're now skipping certain patch releases or just postponing the Renovate PRs until a vet is possible/completed?

Those specific dependencies are getting updated in that patches series because IIRC some other crate required a new minimum version on the road to getting upgraded to support `windows 0.62. I don't remember specifics for these, though...there were many. 😅

Ah, yup, https://github.com/gfx-rs/wgpu/pull/8013/files#diff-13ee4b2252c9e516a0547f2891aa2105c3ca71c6d7a1e682c69be97998dfc87e hits quite a lot of transitive bumps. Wish those were (mostly) unnecessary 😓

[ErichDonGubler]

This was mostly in respect to first being on one end of the spectrum (no response for weeks) to then jumping all the way to the other with force-pushes and respin PRs (something I tend to use sparingly when a contributor hasn't responded for weeks and I really want to get their change in after some minor CI/review fixups).

Ah, that wasn't intended as a respin, sorry! I had pushed branches and a temp PR already so I had a stable point of reference for making sure things were viable in Firefox. I had no illusions that I'd get that through without working with you.

The force-pushes were mostly so I could keep 0.62 changes on top of a rebased set of your patches. I promise I didn't change anything substantially! But then again...force-pushes on others' stuff still usually deserves more explanation than a Compare link, so point taken. Sorry about that! 💦

ETA: Oh, yeah, I had also force-pushed to take care of a TOML formatting failure.

[ErichDonGubler]

Does that mean you're now skipping certain patch releases or just postponing the Renovate PRs until a vet is possible/completed?

Actually, we can have our cake and eat it, too. Renovate actually implements bumping Cargo.lock without forcing a bump in Cargo.toml, so we get benefit from both upgrading and not upgrading. Combined with our MSRV/dep.-minimization checks in CI, it's actually quite nice!

[MarijnS95]

I've dropped all transitive dependency upgrades now, the revert seems to mostly contain windows-sys related bumps that should be consumed via Renovate instead.

Some windows crates had a patch-release from https://github.com/microsoft/windows-rs/releases/70, we can incorporate those as long as they don't affect transitive dependencies.

[ErichDonGubler]

We'll also need microsoft/windows-rs#3785; having case-insensitive collisions b/w README.md and readme.md tripped up initial integration. That seems on track for another patch release, tho!

[MarijnS95]

Oh noes, cased files on a case-insensitive filesystem. /me shudders in include vs Include used in the Vulkan SDK, I have yet to learn how to best set that up for a Windows cross-compile from a Linux machine (for which no Windows-targeted SDK tarball exists...).