Demote Windows MinGW targets to lower tiers or re-enable their tests

The Tier 1 i686 and x86_64 windows mingw targets are broken and have been broken for a long time. The core::arch module hasn’t passed any tests on these targets for months or years. The libc crate doesn’t even link on these targets by default: users need to manually overwrite some of the DLLs that we ship with rustup. Etc.

In all this time, nobody has actually even filled an issue about this, much less submit PRs addressing these issues.

There are many tier 2 targets that are better maintained and tested than these.

So I want to propose to demote them to tier 2, and if they start failing to build, continue demoting them to tier 3.

If at some point a group of maintainers for these targets materializes, and they manage to bring them to tier 2 or tier 3 quality again, we should definitely re-evaluate their tier-status. But in the mean time, it doesn’t make sense to require users that have no interest on these targets working to maintain them.

6 Likes

Really? x86_64 mingw is my primary target on which I develop rustc on daily basis and I haven’t noticed all those listed problems.

Is this the same as the x86_64-pc-windows-gnu target? If not, what is the difference?

I think they are the same. If so, I’ve been providing x86_64-pc-windows-gnu binaries for years now, and AFAIK, they just work, with no special DLL hacks: https://github.com/BurntSushi/ripgrep/blob/master/appveyor.yml — This includes code that uses core::arch.

IIRC, an advantage that x86_64-pc-windows-gnu has over x86_64-pc-windows-msvc, is that the former produces binaries that are standalone on Windows, where as the latter requires users of the binary to have the Visual C++ Redistributable installed. But maybe my knowledge is out of date.

1 Like

Yes, really [0], [1]. Without linking hacks, or without disabling the test suites, CI would be red for these targets, and passing tests is a requirement for tier 1.

Is this the same as the x86_64-pc-windows-gnu target?

Yes.

This includes code that uses core::arch .

core::arch tests haven’t passed there in a long time, and passing tests is a requirement for Tier-1. Those same tests do pass for many Tier-2 targets though.


Moving a target to tier 2 or lower doesn’t mean that the target disappears. It just reflects the state of the target. Many people use tier-2 targets every day without issues.

[0] doesn’t mean that tests don’t pass, it means that tests pass on some limited version range of mingw toolchains, which should be close enough to the pinned toolchain version used by rustc on CI.
If the toolchain version range matches then all tests that are run on merge into rust-lang/rust pass.

That’s not good, of course, but there’s an accepted RFC that is supposed to fix the issue and increase the supported version range - https://github.com/rust-lang/rfcs/pull/2627.

(I’m not sure what [1] is.)

Isn’t this the problem that the rust-mingw component is supposed to fix ?

[1] sets an environment variable to disable running a big part of the core::arch test suite on the target.

Correct me if I’m wrong but I don’t think the vc redist is necessary now that MS have the Universal C Runtime (UCRT) baked in to Windows. Older version of Windows that haven’t been updated in a long time will still need a redist but that’s only necessary if Windows Update hasn’t been run in years.

2 Likes

So apparently the problem here isn’t that these targets have no users, or even developers, so maybe the problem is a communication problem ?

Would it make sense instead to have a team, e.g., @rust-lang/mingw, that gets pinged on issues related to these targets, and that triages them and fixes them ?