-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Add minicore test auxiliary and support //@ add-core-stubs directive in ui/assembly/codegen tests
#130693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@bors try |
[PROTOTYPE] Add minicore test auxiliary and support `//@ use-minicore` directive in ui/assembly/codegen tests **TODO: work in progress prototype implementation, opened early for MCP to reference** Context: [Real cross-compiling tests instead of `#![no_core]` silliness rust-lang#130375](rust-lang#130375) This PR introduces a prototype implementation of `minicore` auxiliary test helper. `minicore` contains 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 is 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, on demand 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). ### Implementation steps - [ ] 1. File an MCP to describe `tests/auxiliary/minicore.rs`, `--minicore-path` compiletest flag, `//@ use-minicore` compiletest directive and the behavior. - [ ] 2. And some self-tests to sanity check the behavior. - [ ] 3. Update rustc-dev-guide to describe the new `use-minicore` directive and provide an example, noting that `use-minicore` both requires `no_std` + `no_core` and implies `-C panic=abort` for the test file. r? `@ghost` (not yet ready for full review, still needs some self-tests and some try-jobs) (TODO: cc interested people once this passes initial try jobs in cross-compilation scenarios) cc `@/workingjubilee` `@/RalfJung` `@/nikic` `@/chrisnc` (if this makes sense to you in terms of functionality and UX) try-job: aarch64-apple try-job: armhf-gnu try-job: x86_64-msvc try-job: test-various try-job: dist-various-1
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
| pub struct ManuallyDrop<T: ?Sized> { | ||
| value: T, | ||
| } | ||
| impl<T: Copy + ?Sized> Copy for ManuallyDrop<T> {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can derive Copy if you add
#[rustc_builtin_macro]
pub macro Copy($item:item) {
/* compiler built-in */
}and the same applies to Clone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not make this change because I couldn't figure out how to make use of this, just kept manual impl Copy for ... for now.
34e9887 to
df03437
Compare
|
Changes since last review:
|
f4a7c38 to
8bd9644
Compare
|
|
||
| /// Builds `minicore`. Returns the path to the minicore rlib within the base test output | ||
| /// directory. | ||
| fn build_minicore(&self) -> PathBuf { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remark: I don't like how convoluted the top-level runtest logic is, but intended for future compiletest cleanup PRs instead of this PR.
//@ use-minicore directive in ui/assembly/codegen testsminicore test auxiliary and support //@ use-minicore directive in ui/assembly/codegen tests
|
r=me with the above change applied. |
The initial `minicore` is intentionally super minimal and contains an incomplete subset of `core` items, and explicitly not items from `alloc` or `std`-only items.
…lude when requested via `//@ add-core-stubs` directive `//@ add-core-stubs` will imply `-Cpanic=abort`.
Check that `minicore` cannot be used with `run-{pass,fail}` tests.
|
@bors r+ |
Add `minicore` test auxiliary and support `//@ add-core-stubs` directive in ui/assembly/codegen tests Context: [Real cross-compiling tests instead of `#![no_core]` silliness rust-lang#130375](rust-lang#130375) MCP: rust-lang/compiler-team#786 Tracking issue: rust-lang#131485 This prototype PR is subject to further changes based on feedback. ### New `minicore` test auxiliary and `//@ add-core-stubs` compiletest directive This PR introduces a prototype implementation of a `minicore` auxiliary test helper that provides `core` stubs for `#![no_core]` ui/assembly/codegen tests that need to build but not run on both the host platform and the cross-compiled target platform. Key summary: - `tests/auxiliary/minicore.rs` contains stub definitions of `core` items intended for consumption by `check-pass`/`build-pass` tests that want the typical prelude items like `Copy` to be stubbed out under `#![no_core]` scenarios, so that the test can be built (not run) for cross-compiled target platforms. Such tests don't want nor need full `-Z build-std` (e.g. `tests/ui/abi/compatibility.rs`). - `minicore` is intended for `core` items **only**, not `std`- or `alloc`-exclusive items. If stubs for `alloc` or `std` are wanted, they should be provided by an additional directive and test auxiliary, and not be conflated with `minicore` or `core` stubs. This is because a wider range of tests can benefit from `core`-only stubs. ### Implementation - The `minicore` auxiliary is a single source file `tests/auxiliary/minicore.rs`. - The path to `minicore` is made avaiable from bootstrap to compiletest via the `--minicore-path` compiletest flag. - `minicore` is then built on-demand via the `//@ add-core-stubs` compiletest directive, for each test revision for the given target platform (this distinction is important for when host platform != target platform in cross-compilation scenario). - `minicore` is then made available to the test as an [extern prelude]. [extern prelude]: https://doc.rust-lang.org/reference/names/preludes.html#extern-prelude ### Example usage ```rs // tests/ui/abi/my-abi-test.rs //@ check-pass //@ add-core-stubs //@ compile-flags: --target i686-unknown-linux-gnu //@ needs-llvm-components: x86 #![feature(no_core, lang_items)] #![no_std] #![no_core] #![allow(unused, internal_features)] extern crate minicore; use minicore::*; #[lang = "clone"] pub trait Clone: Sized { // `Sized` is provided by `minicore` fn clone(&self) -> Self; } ``` ### Implementation steps - [x] 1. Add an initial `minicore` test auxiliary. - [x] 2. Build `minicore` in bootstrap. - [x] 3. Setup a `--minicore-path` compiletest cli flag and pass `minicore` build artifact path from bootstrap to compiletest. - [x] 4. Assert `add-core-stubs` is mutually incompatible with tests that require to be `run`, as the stubs are only good for tests that only need to be built (i.e. no `run-{pass,fail}`). - [x] 5. Add some self-tests to sanity check the behavior. - [x] 6. Ensure that `tests/auxiliary/minicore.rs` is input stamped, i.e. modifying `tests/auxiliary/minicore.rs` should invalidate test cache and force the test to be rerun. ### Known limitations - The current `minicore` is very minimal, because this PR is intended to focus on supporting the test infrastructure first. Further stubs could be added in follow-up PRs and/or on a as-needed basis. try-job: aarch64-apple try-job: armhf-gnu try-job: x86_64-msvc try-job: test-various try-job: dist-various-1
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#130693 (Add `minicore` test auxiliary and support `//@ add-core-stubs` directive in ui/assembly/codegen tests) - rust-lang#132316 (CI: use free runners for 3 fast windows jobs) - rust-lang#132354 (Add `lp64e` RISC-V ABI) - rust-lang#132395 (coverage: Avoid ICE when `coverage_cx` is unexpectedly unavailable) - rust-lang#132396 (CI: use free runners for x86_64-gnu-tools and x86_64-rust-for-linux) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#130693 - jieyouxu:minicore, r=bjorn3 Add `minicore` test auxiliary and support `//@ add-core-stubs` directive in ui/assembly/codegen tests Context: [Real cross-compiling tests instead of `#![no_core]` silliness rust-lang#130375](rust-lang#130375) MCP: rust-lang/compiler-team#786 Tracking issue: rust-lang#131485 This prototype PR is subject to further changes based on feedback. ### New `minicore` test auxiliary and `//@ add-core-stubs` compiletest directive This PR introduces a prototype implementation of a `minicore` auxiliary test helper that provides `core` stubs for `#![no_core]` ui/assembly/codegen tests that need to build but not run on both the host platform and the cross-compiled target platform. Key summary: - `tests/auxiliary/minicore.rs` contains stub definitions of `core` items intended for consumption by `check-pass`/`build-pass` tests that want the typical prelude items like `Copy` to be stubbed out under `#![no_core]` scenarios, so that the test can be built (not run) for cross-compiled target platforms. Such tests don't want nor need full `-Z build-std` (e.g. `tests/ui/abi/compatibility.rs`). - `minicore` is intended for `core` items **only**, not `std`- or `alloc`-exclusive items. If stubs for `alloc` or `std` are wanted, they should be provided by an additional directive and test auxiliary, and not be conflated with `minicore` or `core` stubs. This is because a wider range of tests can benefit from `core`-only stubs. ### Implementation - The `minicore` auxiliary is a single source file `tests/auxiliary/minicore.rs`. - The path to `minicore` is made avaiable from bootstrap to compiletest via the `--minicore-path` compiletest flag. - `minicore` is then built on-demand via the `//@ add-core-stubs` compiletest directive, for each test revision for the given target platform (this distinction is important for when host platform != target platform in cross-compilation scenario). - `minicore` is then made available to the test as an [extern prelude]. [extern prelude]: https://doc.rust-lang.org/reference/names/preludes.html#extern-prelude ### Example usage ```rs // tests/ui/abi/my-abi-test.rs //@ check-pass //@ add-core-stubs //@ compile-flags: --target i686-unknown-linux-gnu //@ needs-llvm-components: x86 #![feature(no_core, lang_items)] #![no_std] #![no_core] #![allow(unused, internal_features)] extern crate minicore; use minicore::*; #[lang = "clone"] pub trait Clone: Sized { // `Sized` is provided by `minicore` fn clone(&self) -> Self; } ``` ### Implementation steps - [x] 1. Add an initial `minicore` test auxiliary. - [x] 2. Build `minicore` in bootstrap. - [x] 3. Setup a `--minicore-path` compiletest cli flag and pass `minicore` build artifact path from bootstrap to compiletest. - [x] 4. Assert `add-core-stubs` is mutually incompatible with tests that require to be `run`, as the stubs are only good for tests that only need to be built (i.e. no `run-{pass,fail}`). - [x] 5. Add some self-tests to sanity check the behavior. - [x] 6. Ensure that `tests/auxiliary/minicore.rs` is input stamped, i.e. modifying `tests/auxiliary/minicore.rs` should invalidate test cache and force the test to be rerun. ### Known limitations - The current `minicore` is very minimal, because this PR is intended to focus on supporting the test infrastructure first. Further stubs could be added in follow-up PRs and/or on a as-needed basis. try-job: aarch64-apple try-job: armhf-gnu try-job: x86_64-msvc try-job: test-various try-job: dist-various-1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is much nicer! Thank you.
Context: Real cross-compiling tests instead of
#![no_core]silliness #130375MCP: rust-lang/compiler-team#786
Tracking issue: #131485
This prototype PR is subject to further changes based on feedback.
New
minicoretest auxiliary and//@ add-core-stubscompiletest directiveThis PR introduces a prototype implementation of a
minicoreauxiliary test helper that providescorestubs for#![no_core]ui/assembly/codegen tests that need to build but not run on both the host platform and the cross-compiled target platform.Key summary:
tests/auxiliary/minicore.rscontains stub definitions ofcoreitems intended for consumption bycheck-pass/build-passtests that want the typical prelude items likeCopyto be stubbed out under#![no_core]scenarios, so that the test can be built (not run) for cross-compiled target platforms. Such tests don't want nor need full-Z build-std(e.g.tests/ui/abi/compatibility.rs).minicoreis intended forcoreitems only, notstd- oralloc-exclusive items. If stubs forallocorstdare wanted, they should be provided by an additional directive and test auxiliary, and not be conflated withminicoreorcorestubs. This is because a wider range of tests can benefit fromcore-only stubs.Implementation
minicoreauxiliary is a single source filetests/auxiliary/minicore.rs.minicoreis made avaiable from bootstrap to compiletest via the--minicore-pathcompiletest flag.minicoreis then built on-demand via the//@ add-core-stubscompiletest directive, for each test revision for the given target platform (this distinction is important for when host platform != target platform in cross-compilation scenario).minicoreis then made available to the test as an extern prelude.Example usage
Implementation steps
minicoretest auxiliary.minicorein bootstrap.--minicore-pathcompiletest cli flag and passminicorebuild artifact path from bootstrap to compiletest.add-core-stubsis mutually incompatible with tests that require to berun, as the stubs are only good for tests that only need to be built (i.e. norun-{pass,fail}).tests/auxiliary/minicore.rsis input stamped, i.e. modifyingtests/auxiliary/minicore.rsshould invalidate test cache and force the test to be rerun.Known limitations
minicoreis very minimal, because this PR is intended to focus on supporting the test infrastructure first. Further stubs could be added in follow-up PRs and/or on a as-needed basis.try-job: aarch64-apple
try-job: armhf-gnu
try-job: x86_64-msvc
try-job: test-various
try-job: dist-various-1