Repository navigation
Real cross-compiling tests instead of #![no_core] silliness #130375
Description
We have a zillion tests that use the #![no_core] hack, like this one:
rust/tests/ui/asm/bad-template.rs
Line 10 in 5e3ede2
A given test involves:
- Host A
- Target B
- Some Rust source (compiled for Target B)
- Test tooling (run on Host A)
Most of our test infra assumes that Host A and Target B are the same thing. This greatly simplifies a lot of assumptions. But this hack we have introduced in so many tests essentially exists so that we can be sure the test runs even when cross-compiling from Host A to Target B. It's possible there's some weird finagling of test flags that can enable this without the hack, but that would be another hack itself. Cross-compiled tests should be relatively easy, like just writing something like:
//@ cross-compile-targets: arch_1-unknown-os_3-env_5 arch_2-unknown-os_4-env_6 arch_1-unknown-os_4-env_5 arch_2-unknown-os_3-env_7
Activity
workingjubilee commentedon Sep 14, 2024
sorry @jieyouxu!
nikic commentedon Sep 16, 2024
The problem here is that without no_core, you actually have to build core/std for the target. We have some tests that test ~all targets, and having everyone build core/std for 100 targets just to run some codegen or assembly tests would be ... not great.
workingjubilee commentedon Sep 16, 2024
That would probably be bad, yes. Handling this correctly probably requires some coordination between bootstrap and compiletest about which stdlibs are built (or can be built, or may be desirable to build).
workingjubilee commentedon Sep 16, 2024
I don't know that we'd even need much to extract information like "Ignored 20 assembly tests with 50 revisions because you didn't build std for aarch64-apple-darwin and 69 other targets."
That would presume treating it like something between
needs-llvm-componentandcompile-flags: --target.It probably wouldn't replace every
no_coretest. But there are many cases whereno_coretests aren't good enough or are too tedious to write so they simply don't get written, and then there's no way to run the test that didn't get written, but if we had at least the core built we could write the tests.RalfJung commentedon Sep 16, 2024
We also have the problem that for most of our targets, you can't easily cross-compile the sysroot. Building a windows std on my Linux host doesn't "just work", at the very least it requires a bunch of tooling to be installed system-wide (because std has C dependencies, and because a linker is needed to build the final artifact). As long as that requirement stands, I think the
no_coreapproach is crucial to be able to let people run and--blessthose tests without having to install all sorts of stuff on their system.We don't actually need
stdfor these tests, though. Can we build a "core-only sysroot" for these targets when needed? That should be faster than building a full sysroot, and it should in principle be possible without any target-specific tools.That said, looking at one of my own no_core tests (
tests/ui/abi/compatibility.rs), I definitely don't want to have to build core 12 times just to be able to run that test on all targets. So I think we want to keep tests like thisno_core. I don't think that's actually such a bad hack, TBH -- the only thing that bothers me about it is having to update all those lang items in a bunch of tests. That can be fixed with aminicore.rsfile that weinclude!into these no_core tests, rather than having to copy-paste the same stuff everywhere.3 remaining items
jieyouxu commentedon Sep 17, 2024
I can work on this, I'm just not sure what the exact design should be.
jieyouxu commentedon Sep 17, 2024
As @compiler-errors mentioned in #130466 (comment), we can probably have something like
//@ aux-build: minicore.rsbut a separate compiletest flag since we don't want to have a copy of minicore.rs under a auxiliary folder relative to every test that needs it.RalfJung commentedon Sep 17, 2024
Yeah I am not sure what is the best way to do this -- something like
tests/util/minicore.rsthat we caninclude!everywhere would work, but maybe an aux-build is better?Maybe this should be an MCP, then more t-compiler people can weigh in.
jieyouxu commentedon Sep 17, 2024
Yeah, I can file a new MCP ~tomorrow so more compiler people can advice.
jieyouxu commentedon Sep 17, 2024
ui tests have the precedent of a C
test_helpers.cfile, so I suppose assembly and codegen tests could get their own special support file lol. Just don't want any hard-to-debug cursedness due to staging and whatever.Auto merge of rust-lang#130693 - jieyouxu:minicore, r=<try>
jieyouxu commentedon Sep 22, 2024
I have a prototype PR at #130693 and opened MCP at rust-lang/compiler-team#786.
Rollup merge of rust-lang#130693 - jieyouxu:minicore, r=bjorn3
Rollup merge of rust-lang#130693 - jieyouxu:minicore, r=bjorn3
Unrolled build for rust-lang#130693