Description
Proposal
The 32-bit Windows GNU target, known by the tuple i686-pc-windows-gnu, remains a problematic target in CI.
We currently claim to offer it tier 1 support, nominally, but it is extremely difficult to maintain it. Some of these problems seem like Windows problems in general, but it is often also bringing in additional problems due to the complexity of also introducing the GNU toolchain. For 32-bit x86 Windows, the target has the additional complexity of having a very constrained amount of resources available.
In general, the tier 1 targets are expected to be something that most contributors can deal with, but in practice, even people who are comfortable with the Windows OS and familiar with its APIs, thus capable of building the necessary target-specific code for Windows, struggle with the windows-gnu target. Even the people who like the target have... interesting... ways of describing the... creative... choices that were required to implement it. And 32-bit Windows is even rougher, of course! Most people are now using 64-bit Windows, which has many important differences.
Given that we can't really realistically expect tier 1 technical support for the i686-pc-windows-gnu target, I propose that we implement the most simple way of dealing with its continuous CI failures in our pipeline: we cease to expect it to execute all our tests in CI, downgrading it to at most tier 2.
Obviously, many of the statements I have made apply to a lesser degree to the following tuples:
i686-pc-windows-msvcx86_64-pc-windows-gnux86_64-pc-windows-msvc
However, all of these see more use and more maintenance, comparatively, and none have the "triple-threat" of being a Windows+GNU kitbash on a 32-bit target. They also have a significantly larger userbase:
| rustc host tuple | 2024 Oct downloads | 2024 Nov downloads | 2024 Dec downloads (c. 25th) |
|---|---|---|---|
| i686-pc-windows-gnu | 53_199 | 56_050 | 48_579 |
| i686-pc-windows-msvc | 162_228 | 242_732 | 240_984 |
| x86_64-pc-windows-gnu | 282_402 | 320_400 | 294_367 |
| x86_64-pc-windows-msvc | 4_738_135 | 4_600_556 | 4_555_129 |
Mentors or Reviewers
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.