Run more tests for rustc_codegen_gcc in the CI

[antoyo]

Proposal

rustc_codegen_gcc was merged in-tree a few years ago and, to this day, it has very limited tests running in the CI.
The issue the maintainers of rustc_codegen_gcc have is that too few tests are ran in the CI and they experience frequent breakages when syncing back the changes in their subtree.
And when that happens, it is not rare that they need to investigate during days or weeks to understand the cause of the issue and to fix it.
They have been spending more and more time fixing these breakages instead of making progress on the codegen.

This MCP proposes to run more tests with rustc_codegen_gcc in the CI so that we don't get these breakages in the first place.
The merge should also be blocked on these tests passing.
At least the following tests would be ran with rustc_codegen_gcc:

• libcore tests
• UI tests
• some additional tests there is in the subtree

All of the above tests (and the tests already running in the CI for rustc_codegen_gcc) would be ran with a standard library compiled with rustc_codegen_gcc in order to detect more breakages.

Since some UI tests currently fail with rustc_codegen_gcc and some other tests are backend-specific, this will require new annotations like:

• //@ ignore-backend: gcc
• //@ needs-backend: gcc

This will change this code in bootstrap and run the new tests in an existing CI task as well as the merge CI.

Prerequisites for this work

To make sure it will be easy for contributors to fix issues found in these tests, the following two tasks will be need to be done before enabling these tests:

• Improve the documentation of rustc_codegen_gcc in the dev guide to explain how to run the tests, how to debug issues and who to contact in case help is needed.
• Make sure the tests can be ran in a single command line: something like ./x test --backend gcc library/core without involving any changes to bootstrap.toml or doing any other kind of setup related to gcc.

Concerns

Some concerns were mentioned on Zulip with regards to the time it will take the Rust developers to make their change in a way that it doesn't break rustc_codegen_gcc.

Mentors or Reviewers

@antoyo is the primary author of rustc_codegen_gcc and will mentor and review code related to this.

@GuillaumeGomez will help with the code needed for the tests.

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.

Note

Concerns (0 active)

• docs-and-contributor-experience resolved in this comment

Managed by @rustbot—see help for details.

[rustbot]

Important

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 can formally be registered here by adding a comment.

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

Concerns can be lifted with:

@rustbot resolve reason-for-concern

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

cc @rust-lang/compiler

[oli-obk]

@rustbot second

[RalfJung]

@rustbot concern docs-and-contributor-experience
Before putting the burden of fixing these test failures onto all contributors, we should ensure the docs and contributor experience for doing that are clear and simple -- ideally, just a normal ./x command. Can we make some example invocations part of the MCP to ensure it is recorded in the proposal?

(I know technical discussion is for Zulip, but the process of raising concerns happens here, and the concern is technical, which means there's technical content here... our process seems a bit self-contradicting here.^^)

[RalfJung]

@rustbot resolve docs-and-contributor-experience
based on #t-compiler/major changes > Run more tests for rustc_codegen_gcc in t… compiler-team#891 @ 💬