Bootstrap command refactoring: port remaining commands with access to Build (step 6) by Kobzol · Pull Request #127680 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation16 Commits4 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Continuation of #127450.
This PR ports commands in bootstrap that can easily get access to Build(er) to BootstrapCommand. After this PR, everything that can access Build(er) should be using the new API.
Statistics of bootstrap code (ignoring src/bin/<shims>) after this PR:
7 usages of `Command::new`
69 usages of `command()` (new API)
- out of that: 16 usages of `as_command_mut()` (new API, but accesses the inner command)
Tracking issue: #126819
r? @onur-ozkan
This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.
Status: Awaiting review from the assignee but also interested parties.
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
labels
This comment has been minimized.
This comment was marked as outdated.
Passes &Builder<'_> to additional places, so that they could use the BootstrapCommand APIs directly, rather than going through as_command_mut.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just one nit suggestion; lgtm otherwise
It was only used in bootstrap. This move allows us to modify the function to work with BootstrapCommand, rather than Command.
📌 Commit 7a54117 has been approved by onur-ozkan
It is now in the queue for this repository.
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
tgross35 added a commit to tgross35/rust that referenced this pull request
…=onur-ozkan
Bootstrap command refactoring: port remaining commands with access to Build (step 6)
Continuation of rust-lang#127450.
This PR ports commands in bootstrap that can easily get access to Build(er) to BootstrapCommand. After this PR, everything that can access Build(er) should be using the new API.
Statistics of bootstrap code (ignoring src/bin/<shims>) after this PR:
7 usages of `Command::new`
69 usages of `command()` (new API)
- out of that: 16 usages of `as_command_mut()` (new API, but accesses the inner command)Tracking issue: rust-lang#126819
r? @onur-ozkan
bors added a commit to rust-lang-ci/rust that referenced this pull request
Rollup of 5 pull requests
Successful merges:
- rust-lang#120990 (Suggest a borrow when using dbg)
- rust-lang#127047 (fix least significant digits of f128 associated constants)
- rust-lang#127680 (Bootstrap command refactoring: port remaining commands with access to
Build(step 6)) - rust-lang#127770 (Update books)
- rust-lang#127780 (Make sure trait def ids match before zipping args in
note_function_argument_obligation)
r? @ghost
@rustbot modify labels: rollup
Finished benchmarking commit (2823cfb): 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 7.0%)
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) | 7.0% | [7.0%, 7.0%] | 1 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | 7.0% | [7.0%, 7.0%] | 1 |
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: 700.173s -> 699.505s (-0.10%)
Artifact size: 328.67 MiB -> 328.65 MiB (-0.01%)
Comment on lines +537 to +543
| let current_branch = helpers::git(Some(&self.src)) |
|---|
| .capture_stdout() |
| .run_always() |
| .args(["symbolic-ref", "--short", "HEAD"]) |
| .run(self) |
| .stdout_if_ok() |
| .map(|s |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This broke working on a detached HEAD:
error message
Updating submodule src/doc/book
fatal: ref HEAD is not a symbolic ref
Command cd "/data/code/rust" && env -u GIT_ALTERNATE_OBJECT_DIRECTORIES -u GIT_DIR -u GIT_INDEX_FILE -u GIT_OBJECT_DIRECTORY -u GIT_WORK_TREE "git" "symbolic-ref" "--short" "HEAD" (failure_mode=Exit, stdout_mode=Capture, stderr_mode=Print) did not execute successfully.
Expected success, got exit status: 128
Created at: src/lib.rs:536:34
Executed at: src/lib.rs:540:18
STDOUT ----
Build completed unsuccessfully in 0:00:00
I think we need .allow_failure() here.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, should be fixed by #127919.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Allow a git command for getting the current branch in bootstrap to fail
Found by @lukas-code [here](rust-lang#127680 (comment)). The bug was introduced in rust-lang#127680 (before, the command was allowed to fail).
r? @onur-ozkan
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#127919 - Kobzol:fix-git-command, r=onur-ozkan
Allow a git command for getting the current branch in bootstrap to fail
Found by @lukas-code [here](rust-lang#127680 (comment)). The bug was introduced in rust-lang#127680 (before, the command was allowed to fail).
r? @onur-ozkan
tgross35 added a commit to tgross35/rust that referenced this pull request
…=onur-ozkan
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
tgross35 added a commit to tgross35/rust that referenced this pull request
…=onur-ozkan
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…=onur-ozkan
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
bors added a commit to rust-lang-ci/rust that referenced this pull request
…nur-ozkan
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
bors added a commit to rust-lang-ci/rust that referenced this pull request
…nur-ozkan
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
bors added a commit to rust-lang-ci/rust that referenced this pull request
…nur-ozkan
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
bors added a commit to rust-lang-ci/rust that referenced this pull request
…nur-ozkan
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
bors added a commit to rust-lang-ci/rust that referenced this pull request
…try>
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
try-job: x86_64-msvc
bors added a commit to rust-lang-ci/rust that referenced this pull request
…nur-ozkan
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang#126819
r? @onur-ozkan
try-job: x86_64-msvc
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of rust-lang/rust#127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just run, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: rust-lang/rust#126819
r? @onur-ozkan
try-job: x86_64-msvc
Labels
This PR was explicitly merged by bors.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)