fix broken build cache caused by rustdoc builds #126934

onur-ozkan · 2024-06-25T08:44:45Z

Currently rustdoc breaks the build cache (due to having different rustflags) when building rustdoc before building another tool (e.g., x test miri && x test rustdoc && x test miri).

This change fixes that by moving on-broken-pipe into prepare_cargo_tool so it is set for all tools.

cc @RalfJung

Fixes #123177

rustbot · 2024-06-25T08:44:54Z

r? @clubby789

rustbot has assigned @clubby789.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

onur-ozkan · 2024-06-25T08:46:50Z

@clubby789 is not active these days and this is a contributor roadblock.

So, r? @Kobzol

RalfJung · 2024-06-25T09:03:04Z

The flag is also set here, is that expected duplication?

rust/src/bootstrap/src/core/build_steps/compile.rs

Lines 1009 to 1011 in 521e707

    
           // If the rustc output is piped to e.g. `head -n1` we want the process to be 
        
           // killed, rather than having an error bubble up and cause a panic. 
        
           cargo.rustflag("-Zon-broken-pipe=kill");

RalfJung · 2024-06-25T09:04:54Z

src/bootstrap/src/core/build_steps/tool.rs

-        // If the rustdoc output is piped to e.g. `head -n1` we want the process
-        // to be killed, rather than having an error bubble up and cause a
-        // panic.
-        cargo.rustflag("-Zon-broken-pipe=kill");


Looks like this was added in cde0cde, regressing the fix I made in #123192. Seems likely this will regress again.

Can you add a comment here saying to not add any rustflags, as that will cause undesired rebuilds?

Can you add a comment here saying to not add any rustflags, as that will cause undesired rebuilds?

We need to duplicate that comment for every impl Step for $tool to make it clear, which wouldn't be not good enough either (because people can miss comments sometimes). As I mentioned in #123177 (comment), I will create a follow-up PR later this week to have this automatically checked. So the test can ensure tools never break the build cache again.

🤷 IMO one can't have too many comments (or at least, that is very hard). Tests are nice but they only catch things after someone already made their PR, when CI runs. And tests can't cover all combinations of tools either.

We definitely need a change that ensures we never end up breaking the cache again (for any tool not just rustdoc).

Added a comment for rustdoc as it's harmless to have.

onur-ozkan · 2024-06-25T09:14:35Z

The flag is also set here, is that expected duplication?

rust/src/bootstrap/src/core/build_steps/compile.rs

Lines 1009 to 1011 in 521e707

// If the rustc output is piped to e.g. `head -n1` we want the process to be

// killed, rather than having an error bubble up and cause a panic.

cargo.rustflag("-Zon-broken-pipe=kill");

This PR changes rustflags for tools and the one you linked is for rustc builds. So, it is expected.

Kobzol · 2024-06-25T09:31:31Z

I wonder if we could return some "sealed" variant of CargoCommand from prepare_tool_cargo, so that it is not possible to modify its rustflags after creation anymore, to prevent issues like this. But it's probably only a problem for tools that are actually a part of a sysroot, like rustdoc, lld-wrapper etc. Maybe we could somehow mark these (in the type system) to make sure that it is not possible to break the cache.

But in any case, that's a more of a long-term goal, this PR looks reasonable as a hotfix.

Kobzol · 2024-06-25T09:44:08Z

The comment is a (slight) improvement over the status quo. Feel free to r=me.

onur-ozkan · 2024-06-25T09:56:48Z

@bors r=Kobzol rollup

bors · 2024-06-25T09:56:51Z

📌 Commit 2e017f4 has been approved by Kobzol

It is now in the queue for this repository.

…obzol fix broken build cache caused by rustdoc builds Currently rustdoc breaks the build cache (due to having different rustflags) when building rustdoc before building another tool (e.g., `x test miri && x test rustdoc && x test miri`). This change fixes that by moving `on-broken-pipe` into `prepare_cargo_tool` so it is set for all tools. cc `@RalfJung` Fixes rust-lang#123177

…mpiler-errors Rollup of 7 pull requests Successful merges: - rust-lang#126893 (Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level) - rust-lang#126907 (Fixes for 32-bit SPARC on Linux) - rust-lang#126932 (Tweak `FlatPat::new` to avoid a temporarily-invalid state) - rust-lang#126934 (fix broken build cache caused by rustdoc builds) - rust-lang#126943 (De-duplicate all consecutive native libs regardless of their options) - rust-lang#126946 (Add missing slash in `const_eval_select` doc comment) - rust-lang#126947 (Delegation: ast lowering refactor) r? `@ghost` `@rustbot` modify labels: rollup

matthiaskrgr · 2024-06-25T16:02:08Z

failed in #126950
@bors r-

Currently rustdoc breaks the build cache (due to having different rustflags) when building rustdoc before building another tool (e.g., `x test miri && x test rustdoc && x test miri`). This change fixes that by moving `on-broken-pipe` into `prepare_cargo_tool` so it is set for all tools. Signed-off-by: onur-ozkan <[email protected]>

onur-ozkan · 2024-06-26T05:28:08Z

@bors r+ rollup=iffy p=1

bors · 2024-06-26T05:28:10Z

📌 Commit b3fb67e has been approved by onur-ozkan

It is now in the queue for this repository.

onur-ozkan · 2024-06-26T05:28:19Z

@bors r-

onur-ozkan · 2024-06-26T05:28:27Z

@bors r=Kobzol

bors · 2024-06-26T05:28:29Z

📌 Commit b3fb67e has been approved by Kobzol

It is now in the queue for this repository.

bors · 2024-06-26T09:42:36Z

⌛ Testing commit b3fb67e with merge bae813a...

bors · 2024-06-26T12:04:56Z

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

rust-timer · 2024-06-26T13:34:41Z

Finished benchmarking commit (bae813a): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary 3.1%)

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)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.1%	[3.1%, 3.1%]	1

Cycles

Results (primary 1.6%)

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)	1.6%	[1.6%, 1.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.6%	[1.6%, 1.6%]	1

Binary size

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

Bootstrap: 694.92s -> 695.46s (0.08%)
Artifact size: 326.70 MiB -> 326.69 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)

rustbot assigned clubby789 Jun 25, 2024

rustbot added 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 Jun 25, 2024

rustbot assigned Kobzol and unassigned clubby789 Jun 25, 2024

onur-ozkan mentioned this pull request Jun 25, 2024

Running ./x.py test miri --stage 0 twice rebuilds miri, cargo-miri, and rustdoc #123177

Closed

RalfJung reviewed Jun 25, 2024

View reviewed changes

onur-ozkan force-pushed the broken-build-cache branch 2 times, most recently from 191f594 to 2e017f4 Compare June 25, 2024 09:43

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 25, 2024

compiler-errors mentioned this pull request Jun 25, 2024

Rollup of 7 pull requests #126950

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 Jun 25, 2024

onur-ozkan force-pushed the broken-build-cache branch 2 times, most recently from 31e997a to 808ac1a Compare June 26, 2024 04:56

This comment has been minimized.

Sign in to view

onur-ozkan force-pushed the broken-build-cache branch from 808ac1a to b3fb67e Compare June 26, 2024 05:04

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 26, 2024

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 Jun 26, 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 26, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 26, 2024

bors merged commit bae813a into rust-lang:master Jun 26, 2024
7 checks passed

rustbot added this to the 1.81.0 milestone Jun 26, 2024

onur-ozkan deleted the broken-build-cache branch June 26, 2024 15:40

This was referenced Oct 1, 2024

Adjusting -Zon-broken-pipe=kill to only be applied to rustc/rustdoc binary wrappers break two cargo tests #131059

Closed

Revert #131060 "Drop conditionally applied cargo -Zon-broken-pipe=kill flags" #131108

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix broken build cache caused by rustdoc builds #126934

fix broken build cache caused by rustdoc builds #126934

onur-ozkan commented Jun 25, 2024 •

edited

Loading

rustbot commented Jun 25, 2024

onur-ozkan commented Jun 25, 2024

RalfJung commented Jun 25, 2024

RalfJung Jun 25, 2024

onur-ozkan Jun 25, 2024 •

edited

Loading

RalfJung Jun 25, 2024

onur-ozkan Jun 25, 2024

onur-ozkan commented Jun 25, 2024

Kobzol commented Jun 25, 2024

Kobzol commented Jun 25, 2024

onur-ozkan commented Jun 25, 2024

bors commented Jun 25, 2024

matthiaskrgr commented Jun 25, 2024

This comment has been minimized.

onur-ozkan commented Jun 26, 2024

bors commented Jun 26, 2024

onur-ozkan commented Jun 26, 2024

onur-ozkan commented Jun 26, 2024

bors commented Jun 26, 2024

bors commented Jun 26, 2024

bors commented Jun 26, 2024

rust-timer commented Jun 26, 2024

fix broken build cache caused by rustdoc builds #126934

fix broken build cache caused by rustdoc builds #126934

Conversation

onur-ozkan commented Jun 25, 2024 • edited Loading

rustbot commented Jun 25, 2024

onur-ozkan commented Jun 25, 2024

RalfJung commented Jun 25, 2024

RalfJung Jun 25, 2024

Choose a reason for hiding this comment

onur-ozkan Jun 25, 2024 • edited Loading

Choose a reason for hiding this comment

RalfJung Jun 25, 2024

Choose a reason for hiding this comment

onur-ozkan Jun 25, 2024

Choose a reason for hiding this comment

onur-ozkan commented Jun 25, 2024

Kobzol commented Jun 25, 2024

Kobzol commented Jun 25, 2024

onur-ozkan commented Jun 25, 2024

bors commented Jun 25, 2024

matthiaskrgr commented Jun 25, 2024

This comment has been minimized.

onur-ozkan commented Jun 26, 2024

bors commented Jun 26, 2024

onur-ozkan commented Jun 26, 2024

onur-ozkan commented Jun 26, 2024

bors commented Jun 26, 2024

bors commented Jun 26, 2024

bors commented Jun 26, 2024

rust-timer commented Jun 26, 2024

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

onur-ozkan commented Jun 25, 2024 •

edited

Loading

onur-ozkan Jun 25, 2024 •

edited

Loading