-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-test-infraArea: test infrastructure (may span bootstrap/compiletest/more)Area: test infrastructure (may span bootstrap/compiletest/more)A-test-infra-minicoreArea: `minicore` test auxiliary and `//@ add-core-stubs`Area: `minicore` test auxiliary and `//@ add-core-stubs`C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
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
A-test-infraArea: test infrastructure (may span bootstrap/compiletest/more)Area: test infrastructure (may span bootstrap/compiletest/more)A-test-infra-minicoreArea: `minicore` test auxiliary and `//@ add-core-stubs`Area: `minicore` test auxiliary and `//@ add-core-stubs`C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.