Description
Proposal
The targets i686-pc-windows-msvc and x86_64-pc-windows-msvc are oddities. They have Tier 1 support for Windows 7+ but also Tier 3 support for Windows XP. This is a legacy from a time when Firefox needed to run on XP. However in the years since they dropped XP support it has mostly been left to bit rot, despite occasional fixes.
I propose that officially dropping this Tier 3 support status would better reflect the actual current level of support for XP and stop burdening a Tier 1 target with the concerns of an effectively unsupported Tier 3 target.
The practical effect this would have on Rust's Windows XP support would be minimal. Major parts of the standard library are already broken on XP (e.g. panics) and even compiling no_std requires configuring the linker. Removing official XP support would not stop anyone from compiling to XP (minus the std) so long as LLVM and their linker still support XP targets.
The effect on Windows 7+ targets would be to remove workarounds and a runtime compatibility layer that enabled support for XP. There might also be the potential for using more modern APIs that may have once been avoided due to compatibility concerns.
If, in the future, there are people motivated to actively support XP then it may be best to create a new target for that purpose. This could be justified on its own merits and its development would not affect development on Tier 1 platforms.
Past threads:
- On WinXP support
- Consider Dropping support for Windows XP
- Is there a timeline for officially ending XP support?
Mentors or Reviewers
If you have a reviewer or mentor in mind for this work, mention then
here. You can put your own name here if you are planning to mentor the
work.
Process
The main points of the Major Change Process is 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.