Description
Proposal
Context
Some of our ui/codegen/assembly tests need to be built for a different target (i.e. cross-compilation scenario). There usually isn't a sysroot immediately available for the designated target nor is it trivial or cheap to build a sysroot for the target (especially as we have many targets). Fortunately, some of these tests don't need a full -Z build-std or sysroot for the target, they only need stubs for core/std prelude items. However, currently the tests don't have a good way to share the stubs, causing test writers to need to copy/paste or reinvent the core/std prelude stubs every time.
EDIT: built not run
Proposed solution
As discussed in #130375, we can introduce a prototype implementation of minicore auxiliary test helper. minicore would contain stub definitions of std/core prelude items intended for consumption by tests that want the typical prelude items like Copy or Result in cross-compilation scenarios, but don't want nor need full -Z build-std (e.g. tests/ui/abi/compatibility.rs).
The minicore auxiliary would be a single source file tests/auxiliary/minicore.rs. The path to this auxiliary is made avaiable from bootstrap to compiletest via the --minicore-path compiletest flag. The minicore auxiliary is then built when request via //@ use-minicore compiletest directives, for each test revision for the given target (this distinction is important for when host != target in cross-compilation scenario).
I have a prototype implementation and how a test (tests/ui/abi/compatibility) looks with the minicore prelude and //@ use-minicore at rust-lang/rust#130693.
Currently only ui/codegen/assembly test modes are intended to be supported.
Mentors or Reviewers
Anyone who is somewhat familiar with compiletest and our ui/codegen/assembly test suites.
@jieyouxu (myself) is happy to review any PRs that fix/improves this feature if this seems reasonable/desirable (I obviously can't approve my own prototype PR).
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 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.