Fix cargo staging for run-make tests #130739

jieyouxu · 2024-09-23T08:59:07Z

Follow-up to #130642 (comment) to make sure that when

$ COMPILETEST_FORCE_STAGE0=1 ./x test run-make --stage 0

is used, bootstrap cargo is used in order to avoid building stage 1 rustc. Note that run-make tests are usually not written with --stage 0 in mind and some tests may rely on stage1 rustc (nightly) behavior, and it is expected that some tests will fail under this invocation.

This PR also fixes tool::Cargo staging in compiletest when preparing for run-make test mode, by chopping off a stage from the compiler passed to tool::Cargo such that when the user invokes with stage N

./x test run-make --stage N

the run-make test suite will be tested against the cargo built by stage N compiler. Let's take N=1, i.e. --stage 1, without chopping off a stage, previously ./x test run-make --stage 1 will cause stage 1 rustc + std to be built, then stage 2 rustc, and cargo will be produced by the stage 2 rustc, which is clearly not what we want. By chopping off a stage, it means that cargo will be produced by the stage 1 rustc.

cc #119946, #59864.
See discussions regarding the tool staging at https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/.E2.9C.94.20stage1.20run-make.20tests.20now.20need.20stage2.20rustc.20built.20for.20c.2E.2E.2E.

jieyouxu · 2024-09-23T09:00:19Z

I tried this locally and it didn't need to build stage1 rustc, but wanted @bjorn3 to double-check in their setup.

src/bootstrap/src/core/build_steps/test.rs

Kobzol · 2024-09-23T11:55:15Z

You can r=me after fixing the cargo invocation.

tests/run-make/thumb-none-cortex-m/rmake.rs

jieyouxu · 2024-09-23T17:17:34Z

cargo invocation is fixed, so

@bors r=@Kobzol rollup

bors · 2024-09-23T17:17:38Z

📌 Commit 6d8150f has been approved by Kobzol

It is now in the queue for this repository.

Pass bootstrap cargo when `--stage 0` and `COMPILETEST_FORCE_STAGE0` Follow-up to rust-lang#130642 (comment) to make sure that when ``` $ COMPILETEST_FORCE_STAGE0=1 ./x test run-make --stage 0 ``` is used, bootstrap cargo is used in order to avoid building stage 1 rustc. Note that run-make tests are usually not written with `--stage 0` in mind and some tests may rely on stage1 rustc (nightly) behavior, and it is expected that some tests will fail under this invocation. cc `@bjorn3` can you please test if this suits your needs for `cg_clif` to avoid the unnecessary stage1 rustc rebuild? r? bootstrap

…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#129545 (rustdoc: redesign toolbar and disclosure widgets) - rust-lang#130618 (Skip query in get_parent_item when possible.) - rust-lang#130727 (Check vtable projections for validity in miri) - rust-lang#130739 (Pass bootstrap cargo when `--stage 0` and `COMPILETEST_FORCE_STAGE0`) - rust-lang#130750 (Add new Tier-3 target: `loongarch64-unknown-linux-ohos`) - rust-lang#130758 (Revert "Add recursion limit to FFI safety lint") - rust-lang#130759 (Update books) - rust-lang#130762 (stabilize const_intrinsic_copy) r? `@ghost` `@rustbot` modify labels: rollup

compiler-errors · 2024-09-24T03:48:01Z

Failed rollup: #130767 (comment)

@bors r-

Kobzol · 2024-09-24T06:38:53Z

Oh, there is another thumb run-make test..

And stop passing `BOOTSTRAP_CARGO` as an env var, instead the provided cargo should go through `--cargo-path.`

tests/run-make/thumb-none-qemu/rmake.rs

jieyouxu · 2024-09-24T09:34:35Z

Wait a minute, does stage 1 cargo rely on stage 2 rustc...? It ends up saying it tests stage1 compiletest but for some reason it needs to build stage2 rustc

I'm getting

Building compiler artifacts (stage1 -> stage2, x86_64-pc-windows-msvc)

but I used ./x test run-make --stage 1. There's something strange happening here with cargo staging?

EDIT: opened https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/stage1.20run-make.20tests.20now.20need.20stage2.20rustc.20built.20for.20cargo.3F, the staging seems all over the place and I have no clue what is happening

Previously if you pass compiler stage 1 to `tool::Cargo`, it will build stage2 rustc and give you back a cargo built with stage2 rustc, which is not what we want. This commit adds a hack that chops off a stage from the compiler passed to `tool::Cargo`, meaning that we will get a cargo built with stage 1 compiler, avoiding unnecessary and incorrect build of stage2 rustc and the cargo built by that.

jieyouxu · 2024-09-24T11:15:21Z

Changes since last review:

Fixed tool::Cargo staging being off-by-one (see updated PR description for more details).
Removed PATH and RUSTC since those env-vars from cargo commands invoked within rmake.rs should inherit the env vars.
Reverted changes to LIB env var in compiler-builtins.

@rustbot ready

Kobzol · 2024-09-24T11:27:57Z

Seems to work, even in combination with download-rustc. You can r=me once CI is green.

jieyouxu · 2024-09-24T12:32:45Z

@bors r=@Kobzol rollup=iffy (some tests I can't run locally, plus bootstrap cargo staging changes for run-make tests)

bors · 2024-09-24T12:32:48Z

📌 Commit f548216 has been approved by Kobzol

It is now in the queue for this repository.

bors · 2024-09-24T22:51:46Z

⌛ Testing commit f548216 with merge 3f99982...

bors · 2024-09-25T02:06:39Z

☀️ Test successful - checks-actions
Approved by: Kobzol
Pushing 3f99982 to master...

rust-timer · 2024-09-25T03:42:28Z

Finished benchmarking commit (3f99982): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

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

Max RSS (memory usage)

Results (secondary -1.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 768.432s -> 767.733s (-0.09%)
Artifact size: 340.84 MiB -> 340.84 MiB (0.00%)

…r-ozkan Revert rust-lang#131060 "Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags" In [rust-lang#131059] we found out that `-Zon-broken-pipe=kill` is actually **load-bearing**[^1] for (at least) `rustc` and `rustdoc` to have the kill-process-on-broken-pipe behavior, e.g. `rustc --print=sysroot | false` will ICE and `rustdoc --print=sysroot | false` will panic on a broken pipe. This PR reverts 5a7058c (reverts PR rust-lang#131060) in favor of a future fix to *unconditionally* apply `-Zon-broken-pipe=kill` to tool builds and also not drop the `-Zon-broken-pipe=kill` flag for rustc binary builds. I could not figure out how to write a regression test for the `rustc --print=sysroot | false` behavior on Unix, so this is a plain revert for now. This revert will unfortunately reintroduce rust-lang#130980 until we fix it again with the different approach. See more details at <rust-lang#131059 (comment)> and in the timeline below. ### Timeline of kill-process-on-broken-pipe behavior changes See [`unix_sigpipe` tracking issue rust-lang#97889][rust-lang#97889] for more context around unix sigpipe handling. - From the very beginning since 2014, Rust binaries by default use `sig_ign`. This meant that if output pipe is broken yet the program tries to use `println!` and such, there will be a broken pipe panic from std. This lead to ICEs from e.g. `rustc --help | false` [rust-lang#34376]. - [rust-lang#49606] mitigated [rust-lang#34376] by adding an explicit signal handler to `rustc_driver` register a sigpipe handler with `SIG_DFL` which will cause the binary using `rustc_driver` to terminate if `rustc_driver::set_sigpipe_handler()` is called. `rustc`'s main binary wrapper uses `rustc_driver::set_sigpipe_handler()`, and so does `rustdoc`. - A more universal way to set sigpipe behavior for Unix was introduced as part of [rust-lang#97889], i.e. `# [unix_sigpipe = "sig_dfl"]` attribute. - [rust-lang#102587] migrated `rustc` to use `#[unix_sigpipe = "sig_dfl"]` instead of `rustc_driver::set_sigpipe_handler`. - [rust-lang#103495] migrated `rustdoc` to use `#[unix_sigpipe = "sig_dfl"]` instead of `rustc_driver::set_sigpipe_handler`. `rustc_driver::set_sigpipe_handler` was removed. - Following concerns about sigpipe setting UI in [rust-lang#97889], the UI for specifying sigpipe behavior was changed in [rust-lang#124480] from `#[unix_sigpipe = "sig_dfl"]` attribute to the commmand line flag `-Zon-broken-pipe=kill`. - In the same PR, `#[unix_sigpipe = "sig_dfl"]` were removed from `rustc` and `rustdoc` main binary crate entry points in favor of the command line flag. Kill-process-on-broken-pipe behavior was preserved by adding `-Zon-broken-pipe=kill` for `rustdoc` tool build step and `rustc` during compile steps. - [rust-lang#126934] added `-Zon-broken-pipe=kill` for tool builds *except* for cargo to help with some miri tests because at the time the PR was written, this would lead to a couple of cargo test failures. Conditionally setting `RUSTFLAGS` can lead to tool build invalidation, e.g. building `cargo` without `-Zon-broken-pipe=kill` but `clippy` with the flag can lead to invalidation of the tool build cache. This is not a problem at the time, because nothing (not even miri) tests built stage 1 cargo (all used initial cargo). - In [rust-lang#130634] we found out that `run-make` tests like `compiler-builtins` needed stage 1 cargo, not just beta bootstrap cargo, because there can be changes that are present in stage 1 cargo but absent in beta cargo, which was blocking a beta backport. - [rust-lang#130642] and later [rust-lang#130739] now build stage 1 cargo. And as previously mentioned, since `-Zon-broken-pipe=kill` was specifically *not* set for cargo, this caused tool build cache invalidation meaning rebuilds of stage 1 even if nothing in source was changed due to differing `RUSTFLAGS` since `run-make` also builds `rustdoc` and such [rust-lang#130980]. [rust-lang#34376]: rust-lang#34376 [rust-lang#49606]: rust-lang#49606 [rust-lang#97889]: rust-lang#97889 [rust-lang#102587]: rust-lang#102587 [rust-lang#103495]: rust-lang#103495 [rust-lang#124480]: rust-lang#124480 [rust-lang#130634]: rust-lang#130634 [rust-lang#130642]: rust-lang#130642 [rust-lang#130739]: rust-lang#130739 [rust-lang#130980]: rust-lang#130980 [rust-lang#131059]: rust-lang#131059 [^1]: rust-lang#131059 (comment) r? `@onur-ozkan` (or bootstrap)

…r-ozkan Revert rust-lang#131060 "Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags" In [rust-lang#131059] we found out that `-Zon-broken-pipe=kill` is actually **load-bearing**[^1] for (at least) `rustc` and `rustdoc` to have the kill-process-on-broken-pipe behavior, e.g. `rustc --print=sysroot | false` will ICE and `rustdoc --print=sysroot | false` will panic on a broken pipe. This PR reverts 5a7058c (reverts PR rust-lang#131060) in favor of a future fix to *unconditionally* apply `-Zon-broken-pipe=kill` to tool builds and also not drop the `-Zon-broken-pipe=kill` flag for rustc binary builds. I could not figure out how to write a regression test for the `rustc --print=sysroot | false` behavior on Unix, so this is a plain revert for now. This revert will unfortunately reintroduce rust-lang#130980 until we fix it again with the different approach. See more details at <rust-lang#131059 (comment)> and in the timeline below. ### Timeline of kill-process-on-broken-pipe behavior changes See [`unix_sigpipe` tracking issue rust-lang#97889][rust-lang#97889] for more context around unix sigpipe handling. - From the very beginning since 2014, Rust binaries by default use `sig_ign`. This meant that if output pipe is broken yet the program tries to use `println!` and such, there will be a broken pipe panic from std. This lead to ICEs from e.g. `rustc --help | false` [rust-lang#34376]. - [rust-lang#49606] mitigated [rust-lang#34376] by adding an explicit signal handler to `rustc_driver` register a sigpipe handler with `SIG_DFL` which will cause the binary using `rustc_driver` to terminate if `rustc_driver::set_sigpipe_handler()` is called. `rustc`'s main binary wrapper uses `rustc_driver::set_sigpipe_handler()`, and so does `rustdoc`. - A more universal way to set sigpipe behavior for Unix was introduced as part of [rust-lang#97889], i.e. `# [unix_sigpipe = "sig_dfl"]` attribute. - [rust-lang#102587] migrated `rustc` to use `#[unix_sigpipe = "sig_dfl"]` instead of `rustc_driver::set_sigpipe_handler`. - [rust-lang#103495] migrated `rustdoc` to use `#[unix_sigpipe = "sig_dfl"]` instead of `rustc_driver::set_sigpipe_handler`. `rustc_driver::set_sigpipe_handler` was removed. - Following concerns about sigpipe setting UI in [rust-lang#97889], the UI for specifying sigpipe behavior was changed in [rust-lang#124480] from `#[unix_sigpipe = "sig_dfl"]` attribute to the commmand line flag `-Zon-broken-pipe=kill`. - In the same PR, `#[unix_sigpipe = "sig_dfl"]` were removed from `rustc` and `rustdoc` main binary crate entry points in favor of the command line flag. Kill-process-on-broken-pipe behavior was preserved by adding `-Zon-broken-pipe=kill` for `rustdoc` tool build step and `rustc` during compile steps. - [rust-lang#126934] added `-Zon-broken-pipe=kill` for tool builds *except* for cargo to help with some miri tests because at the time the PR was written, this would lead to a couple of cargo test failures. Conditionally setting `RUSTFLAGS` can lead to tool build invalidation, e.g. building `cargo` without `-Zon-broken-pipe=kill` but `clippy` with the flag can lead to invalidation of the tool build cache. This is not a problem at the time, because nothing (not even miri) tests built stage 1 cargo (all used initial cargo). - In [rust-lang#130634] we found out that `run-make` tests like `compiler-builtins` needed stage 1 cargo, not just beta bootstrap cargo, because there can be changes that are present in stage 1 cargo but absent in beta cargo, which was blocking a beta backport. - [rust-lang#130642] and later [rust-lang#130739] now build stage 1 cargo. And as previously mentioned, since `-Zon-broken-pipe=kill` was specifically *not* set for cargo, this caused tool build cache invalidation meaning rebuilds of stage 1 even if nothing in source was changed due to differing `RUSTFLAGS` since `run-make` also builds `rustdoc` and such [rust-lang#130980]. [rust-lang#34376]: rust-lang#34376 [rust-lang#49606]: rust-lang#49606 [rust-lang#97889]: rust-lang#97889 [rust-lang#102587]: rust-lang#102587 [rust-lang#103495]: rust-lang#103495 [rust-lang#124480]: rust-lang#124480 [rust-lang#130634]: rust-lang#130634 [rust-lang#130642]: rust-lang#130642 [rust-lang#130739]: rust-lang#130739 [rust-lang#130980]: rust-lang#130980 [rust-lang#131059]: rust-lang#131059 [^1]: rust-lang#131059 (comment) r? ``@onur-ozkan`` (or bootstrap)

Rollup merge of rust-lang#131108 - jieyouxu:revert-broken-pipe, r=onur-ozkan Revert rust-lang#131060 "Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags" In [rust-lang#131059] we found out that `-Zon-broken-pipe=kill` is actually **load-bearing**[^1] for (at least) `rustc` and `rustdoc` to have the kill-process-on-broken-pipe behavior, e.g. `rustc --print=sysroot | false` will ICE and `rustdoc --print=sysroot | false` will panic on a broken pipe. This PR reverts 5a7058c (reverts PR rust-lang#131060) in favor of a future fix to *unconditionally* apply `-Zon-broken-pipe=kill` to tool builds and also not drop the `-Zon-broken-pipe=kill` flag for rustc binary builds. I could not figure out how to write a regression test for the `rustc --print=sysroot | false` behavior on Unix, so this is a plain revert for now. This revert will unfortunately reintroduce rust-lang#130980 until we fix it again with the different approach. See more details at <rust-lang#131059 (comment)> and in the timeline below. ### Timeline of kill-process-on-broken-pipe behavior changes See [`unix_sigpipe` tracking issue rust-lang#97889][rust-lang#97889] for more context around unix sigpipe handling. - From the very beginning since 2014, Rust binaries by default use `sig_ign`. This meant that if output pipe is broken yet the program tries to use `println!` and such, there will be a broken pipe panic from std. This lead to ICEs from e.g. `rustc --help | false` [rust-lang#34376]. - [rust-lang#49606] mitigated [rust-lang#34376] by adding an explicit signal handler to `rustc_driver` register a sigpipe handler with `SIG_DFL` which will cause the binary using `rustc_driver` to terminate if `rustc_driver::set_sigpipe_handler()` is called. `rustc`'s main binary wrapper uses `rustc_driver::set_sigpipe_handler()`, and so does `rustdoc`. - A more universal way to set sigpipe behavior for Unix was introduced as part of [rust-lang#97889], i.e. `# [unix_sigpipe = "sig_dfl"]` attribute. - [rust-lang#102587] migrated `rustc` to use `#[unix_sigpipe = "sig_dfl"]` instead of `rustc_driver::set_sigpipe_handler`. - [rust-lang#103495] migrated `rustdoc` to use `#[unix_sigpipe = "sig_dfl"]` instead of `rustc_driver::set_sigpipe_handler`. `rustc_driver::set_sigpipe_handler` was removed. - Following concerns about sigpipe setting UI in [rust-lang#97889], the UI for specifying sigpipe behavior was changed in [rust-lang#124480] from `#[unix_sigpipe = "sig_dfl"]` attribute to the commmand line flag `-Zon-broken-pipe=kill`. - In the same PR, `#[unix_sigpipe = "sig_dfl"]` were removed from `rustc` and `rustdoc` main binary crate entry points in favor of the command line flag. Kill-process-on-broken-pipe behavior was preserved by adding `-Zon-broken-pipe=kill` for `rustdoc` tool build step and `rustc` during compile steps. - [rust-lang#126934] added `-Zon-broken-pipe=kill` for tool builds *except* for cargo to help with some miri tests because at the time the PR was written, this would lead to a couple of cargo test failures. Conditionally setting `RUSTFLAGS` can lead to tool build invalidation, e.g. building `cargo` without `-Zon-broken-pipe=kill` but `clippy` with the flag can lead to invalidation of the tool build cache. This is not a problem at the time, because nothing (not even miri) tests built stage 1 cargo (all used initial cargo). - In [rust-lang#130634] we found out that `run-make` tests like `compiler-builtins` needed stage 1 cargo, not just beta bootstrap cargo, because there can be changes that are present in stage 1 cargo but absent in beta cargo, which was blocking a beta backport. - [rust-lang#130642] and later [rust-lang#130739] now build stage 1 cargo. And as previously mentioned, since `-Zon-broken-pipe=kill` was specifically *not* set for cargo, this caused tool build cache invalidation meaning rebuilds of stage 1 even if nothing in source was changed due to differing `RUSTFLAGS` since `run-make` also builds `rustdoc` and such [rust-lang#130980]. [rust-lang#34376]: rust-lang#34376 [rust-lang#49606]: rust-lang#49606 [rust-lang#97889]: rust-lang#97889 [rust-lang#102587]: rust-lang#102587 [rust-lang#103495]: rust-lang#103495 [rust-lang#124480]: rust-lang#124480 [rust-lang#130634]: rust-lang#130634 [rust-lang#130642]: rust-lang#130642 [rust-lang#130739]: rust-lang#130739 [rust-lang#130980]: rust-lang#130980 [rust-lang#131059]: rust-lang#131059 [^1]: rust-lang#131059 (comment) r? ``@onur-ozkan`` (or bootstrap)

Revert #131060 "Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags" In [#131059] we found out that `-Zon-broken-pipe=kill` is actually **load-bearing**[^1] for (at least) `rustc` and `rustdoc` to have the kill-process-on-broken-pipe behavior, e.g. `rustc --print=sysroot | false` will ICE and `rustdoc --print=sysroot | false` will panic on a broken pipe. This PR reverts 5a7058c5a542ec42d1fa9b524f7b4f7d6845d1e9 (reverts PR #131060) in favor of a future fix to *unconditionally* apply `-Zon-broken-pipe=kill` to tool builds and also not drop the `-Zon-broken-pipe=kill` flag for rustc binary builds. I could not figure out how to write a regression test for the `rustc --print=sysroot | false` behavior on Unix, so this is a plain revert for now. This revert will unfortunately reintroduce #130980 until we fix it again with the different approach. See more details at <rust-lang/rust#131059 (comment)> and in the timeline below. ### Timeline of kill-process-on-broken-pipe behavior changes See [`unix_sigpipe` tracking issue #97889][#97889] for more context around unix sigpipe handling. - From the very beginning since 2014, Rust binaries by default use `sig_ign`. This meant that if output pipe is broken yet the program tries to use `println!` and such, there will be a broken pipe panic from std. This lead to ICEs from e.g. `rustc --help | false` [#34376]. - [#49606] mitigated [#34376] by adding an explicit signal handler to `rustc_driver` register a sigpipe handler with `SIG_DFL` which will cause the binary using `rustc_driver` to terminate if `rustc_driver::set_sigpipe_handler()` is called. `rustc`'s main binary wrapper uses `rustc_driver::set_sigpipe_handler()`, and so does `rustdoc`. - A more universal way to set sigpipe behavior for Unix was introduced as part of [#97889], i.e. `# [unix_sigpipe = "sig_dfl"]` attribute. - [#102587] migrated `rustc` to use `#[unix_sigpipe = "sig_dfl"]` instead of `rustc_driver::set_sigpipe_handler`. - [#103495] migrated `rustdoc` to use `#[unix_sigpipe = "sig_dfl"]` instead of `rustc_driver::set_sigpipe_handler`. `rustc_driver::set_sigpipe_handler` was removed. - Following concerns about sigpipe setting UI in [#97889], the UI for specifying sigpipe behavior was changed in [#124480] from `#[unix_sigpipe = "sig_dfl"]` attribute to the commmand line flag `-Zon-broken-pipe=kill`. - In the same PR, `#[unix_sigpipe = "sig_dfl"]` were removed from `rustc` and `rustdoc` main binary crate entry points in favor of the command line flag. Kill-process-on-broken-pipe behavior was preserved by adding `-Zon-broken-pipe=kill` for `rustdoc` tool build step and `rustc` during compile steps. - [#126934] added `-Zon-broken-pipe=kill` for tool builds *except* for cargo to help with some miri tests because at the time the PR was written, this would lead to a couple of cargo test failures. Conditionally setting `RUSTFLAGS` can lead to tool build invalidation, e.g. building `cargo` without `-Zon-broken-pipe=kill` but `clippy` with the flag can lead to invalidation of the tool build cache. This is not a problem at the time, because nothing (not even miri) tests built stage 1 cargo (all used initial cargo). - In [#130634] we found out that `run-make` tests like `compiler-builtins` needed stage 1 cargo, not just beta bootstrap cargo, because there can be changes that are present in stage 1 cargo but absent in beta cargo, which was blocking a beta backport. - [#130642] and later [#130739] now build stage 1 cargo. And as previously mentioned, since `-Zon-broken-pipe=kill` was specifically *not* set for cargo, this caused tool build cache invalidation meaning rebuilds of stage 1 even if nothing in source was changed due to differing `RUSTFLAGS` since `run-make` also builds `rustdoc` and such [#130980]. [#34376]: rust-lang/rust#34376 [#49606]: rust-lang/rust#49606 [#97889]: rust-lang/rust#97889 [#102587]: rust-lang/rust#102587 [#103495]: rust-lang/rust#103495 [#124480]: rust-lang/rust#124480 [#130634]: rust-lang/rust#130634 [#130642]: rust-lang/rust#130642 [#130739]: rust-lang/rust#130739 [#130980]: rust-lang/rust#130980 [#131059]: rust-lang/rust#131059 [^1]: rust-lang/rust#131059 (comment) r? ``@onur-ozkan`` (or bootstrap)

rustbot assigned Kobzol Sep 23, 2024

rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Sep 23, 2024

jieyouxu mentioned this pull request Sep 23, 2024

Pass the current cargo to run-make tests #130642

Merged

jieyouxu changed the title ~~Pass bootstrap cargo when --stage 0 and COMPILETST_FORCE_STAGE0~~ Pass bootstrap cargo when --stage 0 and COMPILETEST_FORCE_STAGE0 Sep 23, 2024

jieyouxu commented Sep 23, 2024

View reviewed changes

src/bootstrap/src/core/build_steps/test.rs Outdated Show resolved Hide resolved

jieyouxu force-pushed the stage0_run_make branch from fadd355 to fa083de Compare September 23, 2024 09:48

Kobzol reviewed Sep 23, 2024

View reviewed changes

tests/run-make/thumb-none-cortex-m/rmake.rs Outdated Show resolved Hide resolved

jieyouxu force-pushed the stage0_run_make branch from fa083de to 6d8150f Compare September 23, 2024 12:06

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 Sep 23, 2024

compiler-errors mentioned this pull request Sep 24, 2024

Rollup of 8 pull requests #130767

Closed

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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 24, 2024

Pass bootstrap cargo when --stage 0 and COMPILETST_FORCE_STAGE0

6d132d9

And stop passing `BOOTSTRAP_CARGO` as an env var, instead the provided cargo should go through `--cargo-path.`

jieyouxu force-pushed the stage0_run_make branch from 6d8150f to 9fed38c Compare September 24, 2024 08:01

Kobzol reviewed Sep 24, 2024

View reviewed changes

tests/run-make/thumb-none-qemu/rmake.rs Outdated Show resolved Hide resolved

jieyouxu force-pushed the stage0_run_make branch from 9fed38c to c8bd9c3 Compare September 24, 2024 08:33

This comment has been minimized.

Sign in to view

jieyouxu force-pushed the stage0_run_make branch from c8bd9c3 to 0b24a34 Compare September 24, 2024 09:57

jieyouxu and others added 3 commits September 24, 2024 19:04

Fix run-make-support to respect per-stage cargo

5389792

Update run-make tests to use cargo wrapper cmd

f548216

jieyouxu force-pushed the stage0_run_make branch from 0b24a34 to f548216 Compare September 24, 2024 11:06

jieyouxu changed the title ~~Pass bootstrap cargo when --stage 0 and COMPILETEST_FORCE_STAGE0~~ Fix cargo staging for run-make tests Sep 24, 2024

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 Sep 24, 2024

jieyouxu added the A-compiletest Area: The compiletest test runner label Sep 24, 2024

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 Sep 24, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 25, 2024

bors merged commit 3f99982 into rust-lang:master Sep 25, 2024
7 checks passed

rustbot added this to the 1.83.0 milestone Sep 25, 2024

jieyouxu deleted the stage0_run_make branch September 27, 2024 08:43

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix cargo staging for run-make tests #130739

Fix cargo staging for run-make tests #130739

jieyouxu commented Sep 23, 2024 •

edited

Loading

jieyouxu commented Sep 23, 2024

Kobzol commented Sep 23, 2024

jieyouxu commented Sep 23, 2024

bors commented Sep 23, 2024

compiler-errors commented Sep 24, 2024

Kobzol commented Sep 24, 2024

This comment has been minimized.

jieyouxu commented Sep 24, 2024 •

edited

Loading

jieyouxu commented Sep 24, 2024 •

edited

Loading

Kobzol commented Sep 24, 2024

jieyouxu commented Sep 24, 2024

bors commented Sep 24, 2024

bors commented Sep 24, 2024

bors commented Sep 25, 2024

rust-timer commented Sep 25, 2024

Fix cargo staging for run-make tests #130739

Fix cargo staging for run-make tests #130739

Conversation

jieyouxu commented Sep 23, 2024 • edited Loading

jieyouxu commented Sep 23, 2024

Kobzol commented Sep 23, 2024

jieyouxu commented Sep 23, 2024

bors commented Sep 23, 2024

compiler-errors commented Sep 24, 2024

Kobzol commented Sep 24, 2024

This comment has been minimized.

jieyouxu commented Sep 24, 2024 • edited Loading

jieyouxu commented Sep 24, 2024 • edited Loading

Kobzol commented Sep 24, 2024

jieyouxu commented Sep 24, 2024

bors commented Sep 24, 2024

bors commented Sep 24, 2024

bors commented Sep 25, 2024

rust-timer commented Sep 25, 2024

Overall result: ❌ regressions - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

jieyouxu commented Sep 23, 2024 •

edited

Loading

jieyouxu commented Sep 24, 2024 •

edited

Loading

jieyouxu commented Sep 24, 2024 •

edited

Loading