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.
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.
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.
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.
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 ?
You can just statically link the CRT with the MSVC target and it won't require any redistributible. No need for gnu. The ability to statically link the CRT has been stable for 2 years.
Is part of the problem possibly the rather outdated (last time I checked) MinGW toolchain that the release tarballs for x86_64-pc-windows-gnu ship with?
I've never had any issues with x86_64-pc-windows-gnu via a Rust compiler / toolchain built from scratch through MSYS2 (which provides much more up-to-date versions of all the required tools and libraries than what the tarballs come with via its pacman implementation.)