Closed
Description
Context
We have a bunch of #![no_core]
ui/codegen/assembly tests that roll their own core
prelude stubs because they need to build (but not run) on a cross-compiled target. But this means:
- A bunch of duplicated implementations of
core
prelude stubs scattered in different tests. - A heavy burden on a contributor of possibly having to update many tests if a new required lang item wants to be added.
- Prelude stubs can obfuscate the intent of the test (more things that the reader has to read and mentally filter out).
Instead of continuing to add more copies of core
prelude stubs, let's centralize such core
prelude stubs into a shared test auxiliary called minicore
. minicore
is for core
prelude stubs specifically. std
prelude which can include liballoc
items and such is beyond the scope of minicore
, because core
is usable by more tests. This does not preclude adding another ministd
or minialloc
for stubs of std
/liballoc
respectively.
See #130375 for more discussions.
Steps
- 1. Open an MCP to add
minicore
test auxiliary.- MCP is accepted: Support tests to use
minicore
std/core prelude stubs compiler-team#786 - Note that the MCP title specified std/core prelude stubs, but we revised the scope to
core
stubs only.
- MCP is accepted: Support tests to use
- 2. Implement initial test infra support for
minicore
. - 3. Adjust rustc-dev-guide docs.
- 4.
Figure out the logistics on how to absorbcore
stubs intominicore
, then useminicore
to simplify existing#![no_core]
tests.- Currently, I think it's better to just have the infra in place to allow newer and changed tests to use
minicore.rs
, it seems like unnecessary churn to also force existing tests to useminicore.rs
atm.
- Currently, I think it's better to just have the infra in place to allow newer and changed tests to use
Unresolved questions
- What do we do with existing
#![no_core]
tests that could benefit fromminicore
?
Metadata
Metadata
Assignees
Labels
Area: test infrastructure (may span bootstrap/compiletest/more)Area: `minicore` test auxiliary and `//@ add-core-stubs`Category: An issue tracking the progress of sth. like the implementation of an RFCRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the compiler team, which will review and decide on the PR/issue.