forward the bootstrap `runner` to `run-make` #141856

folkertdev · 2025-06-01T13:33:05Z

The runner was already forwarded to compiletest, this just passes it on to run-make and uses it in the run functions.

The configuration can look like this

# in bootstrap.toml
[target.s390x-unknown-linux-gnu]
runner = "qemu-s390x -L /usr/s390x-linux-gnu"

Any C compilation automatically sets the correct target. Calls to rustc must use .target(target()). Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary:

./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu

The runner can also be used for e.g. running with valgrind.

This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure?

r? @jieyouxu

try-job: test-various
try-job: armhf-gnu

rustbot · 2025-06-01T13:33:11Z

Some changes occurred in src/tools/compiletest

cc @jieyouxu

This PR modifies run-make tests.

cc @jieyouxu

The run-make-support library was changed

cc @jieyouxu

jieyouxu

Thanks, one nit

src/tools/run-make-support/src/run.rs

tests/run-make/c-link-to-rust-va-list-fn/rmake.rs

jieyouxu · 2025-06-01T13:37:54Z

This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure?

Do you happen to know which CI jobs? armhf-gnu?

folkertdev · 2025-06-01T13:43:27Z

I really don't know what cross-compilation actually happens in our CI and would run this run-make test. I've locally run this test for powerpc and s390x. Testing it with a 32-bit arm sounds like a good idea at least.

jieyouxu · 2025-06-01T13:49:12Z

Let's give it a try.
@bors try

…r, r=<try> forward the bootstrap `runner` to `run-make` The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions. The configuration can look like this ```toml # in bootstrap.toml [target.s390x-unknown-linux-gnu] runner = "qemu-s390x -L /usr/s390x-linux-gnu" ``` Any C compilation automatically sets the correct target. Calls to rustc must use `.target(target())`. Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary: ``` ./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu ``` The runner can also be used for e.g. running with `valgrind`. This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure? r? `@jieyouxu` try-job: test-various try-job: armhf-gnu

bors · 2025-06-01T13:50:23Z

⌛ Trying commit ab6646a with merge 1d3fe3c...

jieyouxu · 2025-06-01T13:51:28Z

Reminder (for myself): if try job fails, use @bors2 try to try out new bors

rust-bors · 2025-06-01T13:51:31Z

Unknown command "try`".

bors · 2025-06-01T14:26:38Z

💔 Test failed - checks-actions

jieyouxu · 2025-06-01T14:35:16Z

You probably need sth like //@ ignore-unknown (needs target std)

folkertdev · 2025-06-01T14:56:16Z

Hmm, that directive is never actually used, and also does not solve the issue for that target. It is a known target, just not one that has std (just core I assume). None of the directives in the list seem to really capture this? Maybe needs-threads is a decent proxy but that's not ideal.

jieyouxu · 2025-06-01T15:16:05Z

Yeah, a proper fix is sth like //@ needs-std, but for this PR, //@ ignore-none is a proxy for ignoring the *-unknown targets. I suppose //@ ignore-nvptx is better tho.

EDIT: opened #141863

jieyouxu · 2025-06-01T15:16:28Z

Hmm, that directive is never actually used, and also does not solve the issue for that target. It is a known target, just not one that has std (just core I assume). None of the directives in the list seem to really capture this? Maybe needs-threads is a decent proxy but that's not ideal.

(Sorry, I wrote //@ ignore-unknown but I meant //@ ignore-none as a temporary directive to unblock this PR)

folkertdev · 2025-06-01T15:51:34Z

Apparently you need to explicitly exluce nvptx (several other tests do this).

//@ ignore-none
// Reason: no-std is not supported
//@ ignore-nvptx64-nvidia-cuda
// Reason: can't find crate for 'std'

rust-bors · 2025-06-02T12:06:50Z

⌛ Trying commit e3fee6a with merge 6deab9d…

…r, r=<try> forward the bootstrap `runner` to `run-make` The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions. The configuration can look like this ```toml # in bootstrap.toml [target.s390x-unknown-linux-gnu] runner = "qemu-s390x -L /usr/s390x-linux-gnu" ``` Any C compilation automatically sets the correct target. Calls to rustc must use `.target(target())`. Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary: ``` ./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu ``` The runner can also be used for e.g. running with `valgrind`. This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure? r? `@jieyouxu` try-job: test-various try-job: armhf-gnu

rust-bors · 2025-06-02T12:32:03Z

💔 Test failed

CI ❌

jieyouxu · 2025-06-02T12:33:43Z

Hmm

2025-06-02T12:31:25.8166441Z error: linking with `rust-lld` failed: exit status: 1
2025-06-02T12:31:25.8166509Z   |
2025-06-02T12:31:25.8168630Z   = note:  "rust-lld" "-flavor" "wasm" "--export" "foo" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<2 object files omitted>" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/{libstd-*,libpanic_abort-*,libwasi-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,libcfg_if-*,liblibc-*}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/{liballoc-*,librustc_std_workspace_core-*,libcore-*,libcompiler_builtins-*}.rlib" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/wasm-symbols-not-exported/rmake_out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/self-contained" "-o" "foo.wasm" "--gc-sections" "--no-entry" "-O0"
2025-06-02T12:31:25.8168950Z   = note: some arguments are omitted. use `--verbose` to show all linker arguments
2025-06-02T12:31:25.8169068Z   = note: rust-lld: error: unable to find library -lc

The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions.

folkertdev · 2025-06-02T16:22:27Z

That is weird, it does work for me locally:

> WASI_SDK_PATH="~/Downloads/wasi-sdk-24.0-x86_64-linux" ./x test tests/run-make/c-link-to-rust-va-list-fn --target wasm32-wasip1

...

Testing stage1 compiletest suite=run-make mode=run-make (x86_64-unknown-linux-gnu -> wasm32-wasip1)

running 1 tests

.

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 401 filtered out; finished in 348.41ms

Should we investigate that further, or just ignore wasm32 and wasm64 for now?

jieyouxu · 2025-06-02T16:32:00Z

Should we investigate that further, or just ignore wasm32 and wasm64 for now?

That's a lot of tests, I don't particularly want to regress them like this. I'll try to take a look tmrw.

@rustbot review

folkertdev · 2025-06-02T17:23:59Z

Oh right, the test that I adjusted actually passes, but a bunch of others don't for a variety of reasons. That is really strange, the only thing that change there (I think) is that maybe the runner is set based on bootstrap.toml or other arguments to compiletest.

So the lld thing is weird, but these are even weirder: from alloc-no-oom-handling:

stdout: none
--- stderr -------------------------------
command failed at line 14
Command { cmd: LD_LIBRARY_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/alloc-no-oom-handling/rmake_out:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/lib:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/alloc-no-oom-handling/rmake_out" "--edition" "2021" "-Dwarnings" "--crate-type" "rlib" "/checkout/library/alloc/src/lib.rs" "--cfg" "no_global_oom_handling", stdin_buf: None, stdin: None, stdout: None, stderr: None, drop_bomb: DropBomb { command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc", defused: true, armed_location: Location { file: "/checkout/tests/run-make/alloc-no-oom-handling/rmake.rs", line: 8, col: 5 } }, already_executed: true }
output status: `exit status: 1`
=== STDOUT ===



=== STDERR ===
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-unknown-linux-gnu` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-linux-gnu`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0463`.

One difference I'm seeing is that locally I use stage1 but CI uses stage2. I don't see why that would matter though. In any case I'll push a rebase with the new stage0 machinery.

jieyouxu · 2025-06-04T10:09:28Z

(A bit caught up with other things, I'll take a look on Saturday.)

folkertdev · 2025-06-06T20:03:58Z

src/tools/run-make-support/src/run.rs

+    } else if let Ok(runner) = std::env::var("RUNNER") {
+        let mut args = split_maybe_args(&runner);
+
+        let prog = args.remove(0);
+        let mut cmd = Command::new(prog);
+
+        for arg in args {
+            cmd.arg(arg);
+        }
+
+        cmd.arg("--");
+        cmd.arg(bin_path);
+
        cmd


So, I think the problem is that the wasm tests set the (bootstrap) runner (probably to wasmtime), that now gets forwarded to run-make where it didn't before, and then this bit of code tries to execute any run command with that runner. But the tests in question don't actually expect that, they run on the host instead.

I'm not sure about this, but I think that means that these tests were never really testing what they were supposed to anyway? E.g. alloc-no-oom-handling appears to, currently, just ignore the target completely, and compile and run a host binary.

Hm yeah, e.g. alloc-no-oom-handling are broken re. cross-compile, because it's not cross-by-default, but only opt-in cross ATM with sth like rustc().target(()). I'll try to get #139244 working next week, which might make your life here easier.

jieyouxu · 2025-06-08T13:25:39Z

@rustbot blocked (this change probably needs #139244 first to not have cross-compiled tests catastrophically explode)

Implement `//@ needs-target-std` compiletest directive Closes #141863. Needed to unblock #139244 and #141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with #139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std" try-job: test-various try-job: armhf-gnu

Implement `//@ needs-target-std` compiletest directive Closes rust-lang#141863. Needed to unblock rust-lang#139244 and rust-lang#141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang#139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"

Rollup merge of #142297 - jieyouxu:needs-target-std, r=Kobzol Implement `//@ needs-target-std` compiletest directive Closes #141863. Needed to unblock #139244 and #141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with #139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"

folkertdev · 2025-06-11T23:21:44Z

Would it help if I made a PR that uses needs-target-std for the tests that fail with nvptx here? It looks like that WIP PR is just accumulating merge conflicts, but adding that attribute doesn't really depend on anything and could happen now.

It's kind of tedious but with vim and some music it should be OK.

jieyouxu · 2025-06-11T23:28:24Z

Would it help if I made a PR that uses needs-target-std for the tests that fail with nvptx here? It looks like that WIP PR is just accumulating merge conflicts, but adding that attribute doesn't really depend on anything and could happen now.

That would definitely be appreciated. Let me rebase that PR later today, and I would like to break that PR up into smaller pieces (some e.g. needs-target-std tests could land in a separate PR). I was waiting for the needs-target-std PR to land first.

Implement `//@ needs-target-std` compiletest directive Closes rust-lang/rust#141863. Needed to unblock rust-lang/rust#139244 and rust-lang/rust#141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang/rust#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang/rust#139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"

ignore `run-make` tests that need `std` on targets without `std` In particular, anything that includes `none` in the target triple, and `nvptx64-nvidia-cuda`. Right now we don't cross-compile the `run-make` tests, but we want to in the future. This uses `//@ needs-target-std` introduced in #142297. Useful for #139244 and #141856. The modified files are based on running #141856 locally. It might be that #139244 uncovers some additional files, but that PR needs to be rebased (though actually I'd advice to rebase the non-test changes onto this PR, probably faster that way). r? `@jieyouxu` <details> <summary>vim notes for future me</summary> Make a file with lines like this ``` /home/folkertdev/rust/rust/tests/run-make/export/disambiguator/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/invalid-so/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/no-builtins-attribute/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/export/extern-opt/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/link-dedup/rmake.rs:1:1 ``` then ``` :set errorformat=%f:%l:%c :cfile /tmp/files-to-fix.txt ``` ``` :copen :cnext :cprev ``` are your friends </details> try-job: test-various try-job: armhf-gnu

rustbot assigned jieyouxu Jun 1, 2025

jieyouxu approved these changes Jun 1, 2025

View reviewed changes

src/tools/run-make-support/src/run.rs Outdated Show resolved Hide resolved

tests/run-make/c-link-to-rust-va-list-fn/rmake.rs Show resolved Hide resolved

folkertdev force-pushed the run-make-forward-compiletest-runner branch from 3f206ce to ab6646a Compare June 1, 2025 13:39

jieyouxu mentioned this pull request Jun 1, 2025

New bors looks within markdown code blocks rust-lang/bors#295

Closed

This comment has been minimized.

Sign in to view

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 1, 2025

This comment has been minimized.

Sign in to view

jieyouxu mentioned this pull request Jun 1, 2025

Consider adding a //@ needs-std directive for target std support #141863

Closed

folkertdev force-pushed the run-make-forward-compiletest-runner branch from ab6646a to e3fee6a Compare June 1, 2025 15:52

forward the bootstrap runner to run-make

272dfe8

The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions.

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 2, 2025

folkertdev force-pushed the run-make-forward-compiletest-runner branch from e3fee6a to 272dfe8 Compare June 2, 2025 17:24

folkertdev commented Jun 6, 2025

View reviewed changes

rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 8, 2025

jieyouxu mentioned this pull request Jun 8, 2025

[WIP] [WIP] Enable automatic cross-compilation in run-make tests #139244

Draft

rustbot mentioned this pull request Jun 10, 2025

Implement //@ needs-target-std compiletest directive #142297

Merged

folkertdev mentioned this pull request Jun 12, 2025

ignore run-make tests that need std on targets without std #142414

Open

forward the bootstrap runner to run-make #141856

Are you sure you want to change the base?

forward the bootstrap runner to run-make #141856

Uh oh!

Conversation

folkertdev commented Jun 1, 2025 • edited by jieyouxu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 1, 2025

Uh oh!

jieyouxu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jieyouxu commented Jun 1, 2025

Uh oh!

folkertdev commented Jun 1, 2025

Uh oh!

jieyouxu commented Jun 1, 2025

Uh oh!

bors commented Jun 1, 2025

Uh oh!

jieyouxu commented Jun 1, 2025

Uh oh!

rust-bors bot commented Jun 1, 2025

Uh oh!

This comment has been minimized.

bors commented Jun 1, 2025

Uh oh!

This comment has been minimized.

jieyouxu commented Jun 1, 2025

Uh oh!

folkertdev commented Jun 1, 2025

Uh oh!

jieyouxu commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jieyouxu commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

folkertdev commented Jun 1, 2025

Uh oh!

rust-bors bot commented Jun 2, 2025

Uh oh!

rust-bors bot commented Jun 2, 2025

Uh oh!

jieyouxu commented Jun 2, 2025

Uh oh!

folkertdev commented Jun 2, 2025

Uh oh!

jieyouxu commented Jun 2, 2025

Uh oh!

folkertdev commented Jun 2, 2025

Uh oh!

jieyouxu commented Jun 4, 2025

Uh oh!

folkertdev Jun 6, 2025

Choose a reason for hiding this comment

Uh oh!

jieyouxu Jun 8, 2025

Choose a reason for hiding this comment

Uh oh!

jieyouxu commented Jun 8, 2025

Uh oh!

folkertdev commented Jun 11, 2025

Uh oh!

jieyouxu commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

forward the bootstrap `runner` to `run-make` #141856

forward the bootstrap `runner` to `run-make` #141856

folkertdev commented Jun 1, 2025 •

edited by jieyouxu

Loading

jieyouxu commented Jun 1, 2025 •

edited

Loading

jieyouxu commented Jun 1, 2025 •

edited

Loading

jieyouxu commented Jun 11, 2025 •

edited

Loading