Deduplicate test suites for alternative codegen backends
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
Currently, the cranelift and gcc codegen backends have tiny test suites in their respective folders that get run in rustc CI:
- https://github.com/rust-lang/rust/tree/ec0b3540925af3cab9c38b0344902d48edb9d5b8/compiler/rustc_codegen_cranelift/example
- https://github.com/rust-lang/rust/tree/ec0b3540925af3cab9c38b0344902d48edb9d5b8/compiler/rustc_codegen_gcc/example
My understanding is that these are basically smoke-tests, but they use a lot of low-level internal and unstable APIs that keep changing, making them a maintenance hazard. As you can easily see, there's also a lot of duplication between them. I don't even know often I had to fix the mini_core tests (looks like both backends have two of them, for some reason). PRs like https://github.com/rust-lang/rust/pull/128731 would benefit from adding another test there (ui/simd/shuffle.rs, in that case), but I don't want to add even more duplication.
Is there any way we can deduplicate this? The first idea that comes to my mind is that instead of having these example files stored as copies in the respective backends, we have a run-tests.txt file (or so) that lists a bunch of filenames relative to tests/ui that should be built and run with the backend. That means
- One can easily ensure that the test itself type-checks and works as intended using
./x.py test ui, without even having to do the setup required for the alternative codegen backend. - The test is shared between all backends, reducing duplication.
- For cases like #128731, one can just easily add another test to the list, when it turns out there is an interesting special case to cover.
Cc @bjorn3 @antoyo @GuillaumeGomez
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Compare the duplicated smoke tests in compiler/rustc_codegen_cranelift/example and compiler/rustc_codegen_gcc/example, then inspect how ./x.py test ui discovers and runs tests. Evaluate a run-tests.txt-style list of tests under tests/ui, with done meaning the shared tests can run with the alternative backends without duplicated copies.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, testing
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100