-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bootstrap command refactoring: consolidate output modes (step 3) #127120
Conversation
This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp. This PR modifies If appropriate, please update |
This comment has been minimized.
This comment has been minimized.
463bc8d
to
31c3983
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
740f4e0
to
b92344e
Compare
This comment has been minimized.
This comment has been minimized.
b92344e
to
67d6eb1
Compare
This comment was marked as outdated.
This comment was marked as outdated.
67d6eb1
to
e631949
Compare
This comment has been minimized.
This comment has been minimized.
e631949
to
7a0fa5a
Compare
src/bootstrap/src/utils/exec.rs
Outdated
@@ -32,17 +35,20 @@ pub enum OutputMode { | |||
/// If you want to delay failures until the end of bootstrap, use [delay_failure]. | |||
/// | |||
/// By default, the command will print its stdout/stderr to stdout/stderr of bootstrap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keeping ([OutputMode::Print]).
part alone on the next line seems annoying
/// By default, the command will print its stdout/stderr to stdout/stderr of bootstrap | |
/// By default, the command will print its stdout/stderr to stdout/stderr of bootstrap ([OutputMode::Print]). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, I thought that doc comments need to be within 100 characters on a line, but tidy doesn't complain. Ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah tidy doesn't check line lengths in source files as it can be quite annoying to wrap lines that contain code.
src/bootstrap/src/utils/exec.rs
Outdated
/// Captures the stdout of the command into memory, inherits stderr. | ||
/// Corresponds to calling `cmd.output()`. | ||
CaptureStdout, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CaptureStdout
explicitly mentions stdout in its name, why does it also inherit stderr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if you capture (only) stdout, you need to do something with stderr (instead of capturing it). You can either ignore it or inherit it (so that it will be printed to the stderr of bootstrap). Ignoring output seems bad, and all previous usages of this mode inherited stderr, so I suppose that it makes sense as a default?
CaptureStdout
- capture stdout, print stderrCaptureAll
- capture both stdout and stderr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so I suppose that it makes sense as a default?
I have no objections to making it the default behaviour. My point was it's unclear to me that a type explicitly mentions stdout
and inherits stderr
, which I'm pretty sure most people will not expect until they read the type's doc-comment. It's just about the name-description clarity, not about whether this behavior should be the default or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see :) Any suggestions? CaptureStdoutPrintStderr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that seems more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried to refactor this in a more general way, as the name reminded me of Java too much.
@@ -246,6 +244,7 @@ macro_rules! bootstrap_tool { | |||
; | |||
)+) => { | |||
#[derive(PartialEq, Eq, Clone)] | |||
#[allow(dead_code)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's becoming unused in this macro? Worth to add a FIXME
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically it is Tool::JsonDocCk
and Tool::JsonDocLint
. For some reason, the compiler thought that they were used before this PR, probably because of some false positive (?). I haven't found anything in this PR that would remove their usage.
In general, I don't think that this should be a FIXME. The Tool
enum is generated by a macro, and not all tools need to be built using tool_cmd
, so it may be unused. The macro uses these two enum variants in the tool_exe
function, but it is probably ignored by the compiler since the usage is inside a macro.
builder.run(BootstrapCommand::from(&mut tool).output_mode(OutputMode::OnlyOnFailure)); | ||
builder.run(tool.capture()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is CaptureAll
the new equivalent for OnlyOnFailure
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I think we changed the variant names of this enum like 3 times already.. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is CaptureAll the new equivalent for OnlyOnFailure?
CaptureAll
is essentially OnlyOnFailure
, yes. I made the decision whether to print something during a command failure fully derived from other options, rather than configurable by users, because it was introducing unnecessary complexity to the command and it was only used in two places of bootstrap anyway. We should IMO always print failures, unless the failure is explicitly ignored.
Also, I think we changed the variant names of this enum like 3 times already.. 😄
Well, refactoring is a continuous process, at least for me :) First I was trying to make the names as similar to the previous names used ad hoc in bootstrap code, to make it easier fo review that the migration is doing the same thing as before. Now that the usages of BootstrapCmd
have been migrated, it was time to make the names better.
@rustbot ready |
a47933f
to
8dc4485
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Let's make it easier to revert for worst-case scenarios. @bors rollup=never |
…nur-ozkan Bootstrap command refactoring: consolidate output modes (step 3) This PR is a continuation to rust-lang#126731. It consolidates the output modes of bootstrap (`Print` vs `CaptureAll` vs `CaptureStdout`) and simplifies the logic around error printing (now a command error is always printed if the failure is not ignored). It also ports even more usages of `Command` to `BootstrapCommand`, most notably the git helpers and many usages of the `output` function. The last commit was added because the third commit made two variants of the `Tool` enum unused (no idea why, but it seems to have been a false positive that they were used before). It can be reviewed now, but I would wait with merging until at least a few days after rust-lang#126731, just to catch any potential issues from that PR before we move further. As a next step, I want to clean up the API of the command a little bit to make usage easier (currently it's a bit verbose), and then continue with the rest of the tasks from the tracking issue. As always, best reviewed commit by commit. Tracking issue: rust-lang#126819 r? `@onur-ozkan`
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
When dry run is enabled, the command for finding LLDB version would succeed, but return an empty string. This was inadvertently enabling a code path that should only be executed when the LLDB is actually present and its version is valid. This commit makes sure that if the version is empty, LLDB will be considered not found.
@bors try |
…try> Bootstrap command refactoring: consolidate output modes (step 3) This PR is a continuation to rust-lang#126731. It consolidates the output modes of bootstrap (`Print` vs `CaptureAll` vs `CaptureStdout`) and simplifies the logic around error printing (now a command error is always printed if the failure is not ignored). It also ports even more usages of `Command` to `BootstrapCommand`, most notably the git helpers and many usages of the `output` function. The last commit was added because the third commit made two variants of the `Tool` enum unused (no idea why, but it seems to have been a false positive that they were used before). It can be reviewed now, but I would wait with merging until at least a few days after rust-lang#126731, just to catch any potential issues from that PR before we move further. As a next step, I want to clean up the API of the command a little bit to make usage easier (currently it's a bit verbose), and then continue with the rest of the tasks from the tracking issue. As always, best reviewed commit by commit. Tracking issue: rust-lang#126819 r? `@onur-ozkan` try-job: aarch64-apple
☀️ Try build successful - checks-actions |
Fixed problem with dry run in Apple job. @bors r=onur-ozkan |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e2cf31a): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary 0.2%)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.
CyclesResults (secondary -1.7%)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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 718.904s -> 734.204s (2.13%) |
…nur-ozkan Bootstrap command refactoring: quality-of-life improvements (step 4) Continuation of rust-lang#127120. This PR simply introduce two new functions (`BootstrapCommand:run` and `command`) that make it a bit easier to use commands in bootstrap. It also adds several `#[must_use]` annotations. This shouldn't (hopefully) have any effect on behavior. Especially the first commit IMO makes any code that runs commands more readable, and allows using the API in a fluent way, without needing to jump back and forth between the command and the `Build(er)`. Tracking issue: rust-lang#126819 r? `@onur-ozkan`
Bootstrap command refactoring: quality-of-life improvements (step 4) Continuation of rust-lang/rust#127120. This PR simply introduce two new functions (`BootstrapCommand:run` and `command`) that make it a bit easier to use commands in bootstrap. It also adds several `#[must_use]` annotations. This shouldn't (hopefully) have any effect on behavior. Especially the first commit IMO makes any code that runs commands more readable, and allows using the API in a fluent way, without needing to jump back and forth between the command and the `Build(er)`. Tracking issue: rust-lang/rust#126819 r? `@onur-ozkan`
Bootstrap command refactoring: quality-of-life improvements (step 4) Continuation of rust-lang/rust#127120. This PR simply introduce two new functions (`BootstrapCommand:run` and `command`) that make it a bit easier to use commands in bootstrap. It also adds several `#[must_use]` annotations. This shouldn't (hopefully) have any effect on behavior. Especially the first commit IMO makes any code that runs commands more readable, and allows using the API in a fluent way, without needing to jump back and forth between the command and the `Build(er)`. Tracking issue: rust-lang/rust#126819 r? `@onur-ozkan`
This PR is a continuation to #126731. It consolidates the output modes of bootstrap (
Print
vsCaptureAll
vsCaptureStdout
) and simplifies the logic around error printing (now a command error is always printed if the failure is not ignored). It also ports even more usages ofCommand
toBootstrapCommand
, most notably the git helpers and many usages of theoutput
function.The last commit was added because the third commit made two variants of the
Tool
enum unused (no idea why, but it seems to have been a false positive that they were used before).It can be reviewed now, but I would wait with merging until at least a few days after #126731, just to catch any potential issues from that PR before we move further.
As a next step, I want to clean up the API of the command a little bit to make usage easier (currently it's a bit verbose), and then continue with the rest of the tasks from the tracking issue.
As always, best reviewed commit by commit.
Tracking issue: #126819
r? @onur-ozkan
try-job: aarch64-apple