ci: move x86_64-msvc-ext jobs to windows 2025

[marcoieni]

These jobs are a bit flaky. See this zulip thread and this GitHub issue.
Windows 2025 is working well for x86_64-msvc jobs since we moved them in #135632

Analysis

• The jobs x86_64-msvc-ext2 and x86_64-msvc-ext3 never failed in the last month
• The job x86_64-msvc-ext1 failed 6 times:
  

try-job: x86_64-msvc-ext1
try-job: x86_64-msvc-ext2
try-job: x86_64-msvc-ext3

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[marcoieni]

@bors try

[bors]

⌛ Trying commit e9925ae with merge bfe1bef...

[bors]

💔 Test failed - checks-actions

[marcoieni]

weird error 🤔
Has anybody seen this before?

[ChrisDenton]

The test is here: https://github.com/rust-lang/cargo/blob/0e3d73849ab8cbbab3ec5c65cbd555586cb21339/tests/testsuite/package.rs#L2847

On newer versions of Windows those "reserved" names are allowed so the test fails. Which Cargo seems to be aware of given the test is gated by https://github.com/rust-lang/cargo/blob/0e3d73849ab8cbbab3ec5c65cbd555586cb21339/crates/cargo-test-support/src/paths.rs#L373.

However, that is set to always return false in CI. Probably should open an issue with Cargo asking how they want to proceed.

[marcoieni]

Thanks a lot! Opened rust-lang/cargo#15135

[marcoieni]

The cargo PR was merged. Now we need to wait for the cargo team to update cargo inside this repository.
I.e. a PR similar to #136376

[marcoieni]

@bors try

[bors]

⌛ Trying commit 131e3fe with merge c5b7ac2...

[bors]

☀️ Try build successful - checks-actions
Build commit: c5b7ac2 (c5b7ac29644dfa4a299af06c98ae34c170fa074b)

[marcoieni]

@rustbot ready

[Mark-Simulacrum]

IIUC, this continues to decrease our test coverage for older Windows, right? Arguably it makes Windows 2025 "more" a tier 1 target and Windows 10(?) more of a tier 2 target. Historically we haven't made much of that, but I'm wondering if folks more familiar with Windows think we should be trying to do something else here or at least documenting that change somewhere in our platform support policies, presuming I'm following correctly.

[ChrisDenton]

I'd note for completeness that "Windows 10" isn't a single OS version. It spans about 7 years of development and 12 "feature" releases (e.g. new APIs, etc). Even with Windows Server 2019 we're testing way above RTM Windows 10. Arguably for our use the change from Server 2016 to Server 2019 was a much bigger jump than from 2019 to 2025 because the newer APIs we conditionally use are all available on 2019. Which is to say this has long been an issue but, yeah, it's mostly a documentation issue given our constraints.

Ultimately it would be great if we have more versions to test in CI so perhaps we can make more use of the ones we do have access to. Maybe we could have a job that runs ./x test library/std --stage 2 on the older Windows? Compiling a stage 2 compiler would be a pretty effective test in itself and I'd suspect std is (potentially) the most sensitive to Windows version changes.

[Mark-Simulacrum]

Which is to say this has long been an issue but, yeah, it's mostly a documentation issue given our constraints.

Yeah, makes sense. I'd be OK not doing anything in this PR, I think, given the current state of things, but it would probably be good to have some discussion/updates to the platform support docs to reflect the reality of what we test (and don't test).

Ultimately it would be great if we have more versions to test in CI so perhaps we can make more use of the ones we do have access to. Maybe we could have a job that runs ./x test library/std --stage 2 on the older Windows? Compiling a stage 2 compiler would be a pretty effective test in itself and I'd suspect std is (potentially) the most sensitive to Windows version changes.

It sounds plausible so long as we have relatively easy access to older Windows, which I guess probably isn't going to be true for long? Not sure what the plans are in Microsoft or GitHub for long-term availability of the Windows 10 runners (or Windows 10 itself).

I'm OK moving forward with this if there's no blockers from the windows maintainers side (r=me).