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

jieyouxu · 2025-06-01T13:35:09Z

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


 fn main() {
-    rustc().input("checkrust.rs").run();
+    rustc().input("checkrust.rs").target(target()).run();


Remark: this will not be needed if I finish auto-cross #139244

I removed target(target() bit now (yay!) and use the new needs-target-std in that test file.

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'

bors · 2025-06-21T13:05:16Z

⌛ Testing commit d023fe7 with merge 7d1b2c0...

…r, r=jieyouxu 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-21T14:47:37Z

💔 Test failed - checks-actions

folkertdev · 2025-06-21T15:53:35Z

Hmm, https://developer.android.com/ndk/guides/stable_apis#c_library makes me believe that maybe -lrt should not be passed on android?

Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against.

Should we dig into that, or just ignore android here? (at the moment, most run-make tests that compile C disable cross-compilation one way or another)

jieyouxu · 2025-06-21T23:29:48Z

Could you open an issue about this being broken, then disable android and slap a FIXME pointing to that issue?

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-21T23:40:48Z

Done #142855. A try run for android doesn't seem that valuable, so I guess we just see what bors says again?

jieyouxu · 2025-06-21T23:47:48Z

Yeah, seems fine.
@bors r+

bors · 2025-06-21T23:47:50Z

📌 Commit 0d4abfc has been approved by jieyouxu

It is now in the queue for this repository.

bors · 2025-06-22T02:21:16Z

⌛ Testing commit 0d4abfc with merge 8051f01...

bors · 2025-06-22T05:21:33Z

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing 8051f01 to master...

github-actions · 2025-06-22T05:24:45Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing fa2f355 (parent) -> 8051f01 (this PR)

Test differences

Show 3 test diffs

Stage 2

[run-make] tests/run-make/c-link-to-rust-va-list-fn: ignore (ignored when cross-compiling) -> ignore (ignored when the operating system is android (FIXME(run-make: cross-compiling C to android fails #142855))) (J0)
[run-make] tests/run-make/c-link-to-rust-va-list-fn: ignore (ignored when cross-compiling) -> ignore (ignored if target does not support std) (J1)
[run-make] tests/run-make/c-link-to-rust-va-list-fn: ignore (ignored when cross-compiling) -> pass (J2)

Job group index

J0: arm-android
J1: dist-various-1
J2: armhf-gnu, dist-i586-gnu-i586-i686-musl, test-various

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 8051f012658fde822bfc661b52e90950b411e5c9 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-apple-2: 3715.6s -> 6536.7s (75.9%)
x86_64-apple-1: 7013.4s -> 8767.5s (25.0%)
dist-apple-various: 5756.3s -> 6762.1s (17.5%)
mingw-check-tidy: 70.1s -> 80.8s (15.3%)
x86_64-rust-for-linux: 2520.4s -> 2881.2s (14.3%)
x86_64-gnu-tools: 3205.9s -> 3661.6s (14.2%)
x86_64-gnu-miri: 4529.7s -> 5155.2s (13.8%)
i686-gnu-1: 7160.8s -> 8016.1s (11.9%)
i686-gnu-2: 5588.7s -> 6232.0s (11.5%)
mingw-check-1: 1557.1s -> 1735.0s (11.4%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-06-22T07:40:30Z

Finished benchmarking commit (8051f01): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.8%	[-2.8%, -2.8%]	1

Max RSS (memory usage)

Results (primary 2.7%, secondary 1.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.7%	[1.4%, 4.0%]	2
Regressions ❌ (secondary)	3.5%	[1.2%, 5.9%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.1%	[-2.1%, -2.1%]	1
All ❌✅ (primary)	2.7%	[1.4%, 4.0%]	2

Cycles

Results (primary -2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.7%	[-2.7%, -2.7%]	1

Binary size

Results (primary -1.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.1%	[-1.1%, -1.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.1%	[-1.1%, -1.1%]	1

Bootstrap: 689.982s -> 690.748s (0.11%)
Artifact size: 371.93 MiB -> 371.94 MiB (0.00%)

Enable automatic cross-compilation in run-make tests Supersedes rust-lang/rust#138066. Blocker for rust-lang/rust#141856. Based on rust-lang/rust#138066 plus `rustdoc()` cross-compile changes. ### Summary This PR automatically specifies `--target` to `rustc()` and `rustdoc()` to have `rustc`/`rustdoc` produce cross-compiled artifacts in run-make tests by default, unless: - `//@ ignore-cross-compile` is used, or - `bare_{rustc,rustdoc}` are used, or - Explicit `.target()` is specified, which overrides the default cross-compile target. Some tests are necessarily modified: - Tests that have `.target(target())` have that incantation removed (since this is now automatically the default). - Some tests have `//@ needs-target-std`, but are a necessary-but-insufficient condition, and are changed to `//@ ignore-cross-compile` instead as host-only tests. - A few tests received `//@ ignore-musl` that fail against `x86_64-unknown-linux-musl` because of inability to find `-lunwind`. AFAICT, they don't *need* to test cross-compiled artifacts. - Some tests are constrained to host-only for now, because the effort to make them pass on cross-compile does not seem worth the complexity, and it's not really *meaningfully* improving test coverage. try-job: dist-various-1

…ink-to-rust-va-list-fn_test, r=jieyouxu [RTE-497] Ignore `c-link-to-rust-va-list-fn` test on SGX platform rust-lang#141856 enables using the runner defined in bootstrap.toml to execute run-make tests. A test was added for this feature that compiles a Rust library and C code, links them together and passes the result to the runner. Unfortunately, that's not sufficient for the SGX platform; x86 machine code cannot be directly executed. This PR fixes the issue by disabling this test for SGX.

Rollup merge of #142965 - raoulstrackx:raoul/rte-497-fix_c-link-to-rust-va-list-fn_test, r=jieyouxu [RTE-497] Ignore `c-link-to-rust-va-list-fn` test on SGX platform #141856 enables using the runner defined in bootstrap.toml to execute run-make tests. A test was added for this feature that compiles a Rust library and C code, links them together and passes the result to the runner. Unfortunately, that's not sufficient for the SGX platform; x86 machine code cannot be directly executed. This PR fixes the issue by disabling this test for SGX.

rustbot assigned jieyouxu Jun 1, 2025

jieyouxu approved these changes Jun 1, 2025

View reviewed changes

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

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 21, 2025

This comment has been minimized.

Sign in to view

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 21, 2025

folkertdev mentioned this pull request Jun 21, 2025

run-make: cross-compiling C to android fails #142855

Open

forward the bootstrap runner to run-make

0d4abfc

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

folkertdev force-pushed the run-make-forward-compiletest-runner branch from d023fe7 to 0d4abfc Compare June 21, 2025 23:38

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 21, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 22, 2025

bors merged commit 8051f01 into rust-lang:master Jun 22, 2025
11 checks passed

rustbot added this to the 1.89.0 milestone Jun 22, 2025

raoulstrackx mentioned this pull request Jun 24, 2025

[RTE-497] Ignore c-link-to-rust-va-list-fn test on SGX platform #142965

Merged

forward the bootstrap runner to run-make #141856

forward the bootstrap runner to run-make #141856

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!

jieyouxu Jun 1, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev Jun 1, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev Jun 19, 2025

Choose a reason for hiding this comment

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!

bors commented Jun 21, 2025

Uh oh!

This comment has been minimized.

bors commented Jun 21, 2025

Uh oh!

folkertdev commented Jun 21, 2025

Uh oh!

jieyouxu commented Jun 21, 2025

Uh oh!

folkertdev commented Jun 21, 2025

Uh oh!

jieyouxu commented Jun 21, 2025

Uh oh!

bors commented Jun 21, 2025

Uh oh!

bors commented Jun 22, 2025

Uh oh!

bors commented Jun 22, 2025

Uh oh!

Uh oh!

github-actions bot commented Jun 22, 2025

Test differences

Stage 2

Job duration changes

Uh oh!

rust-timer commented Jun 22, 2025

Overall result: ✅ improvements - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

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