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

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 added 2 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

jieyouxu mentioned this pull request Oct 9, 2024

[beta] backports #131423

Merged

jieyouxu mentioned this pull request Mar 27, 2025

ICE: trimmed_def_paths called, diagnostics were expected but none were emitted. #138979

Closed

Fix cargo staging for run-make tests #130739

Fix cargo staging for run-make tests #130739

Uh oh!

Conversation

jieyouxu commented Sep 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jieyouxu commented Sep 23, 2024

Uh oh!

Uh oh!

Kobzol commented Sep 23, 2024

Uh oh!

Uh oh!

jieyouxu commented Sep 23, 2024

Uh oh!

bors commented Sep 23, 2024

Uh oh!

compiler-errors commented Sep 24, 2024

Uh oh!

Kobzol commented Sep 24, 2024

Uh oh!

Uh oh!

This comment has been minimized.

jieyouxu commented Sep 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jieyouxu commented Sep 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kobzol commented Sep 24, 2024

Uh oh!

jieyouxu commented Sep 24, 2024

Uh oh!

bors commented Sep 24, 2024

Uh oh!

bors commented Sep 24, 2024

Uh oh!

bors commented Sep 25, 2024

Uh oh!

Uh oh!

rust-timer commented Sep 25, 2024

Overall result: ❌ regressions - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Uh oh!

jieyouxu commented Sep 23, 2024 •

edited

Loading

jieyouxu commented Sep 24, 2024 •

edited

Loading

jieyouxu commented Sep 24, 2024 •

edited

Loading