Demote i686-pc-windows-gnu

[workingjubilee]

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-msvc
• x86_64-pc-windows-gnu
• x86_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

• @ChrisDenton
• @mati865

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 merge on either the MCP or the PR.
• 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.

[rustbot]

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.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rfcbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rfcbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[Noratrieb]

I think we should wait one or two weeks with seconding this (or extend the manually-managed 10-day period to a longer time) to avoid this happening over what is the holidays for many contributors.