Rollup of 5 pull requests #126825
Closed
Rollup of 5 pull requests #126825
Conversation
This file contains 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
When we have long code skips, we write `...` in the line number gutter. For suggestions, we were "centering" the `...` with the line, but that was consistent with what we do in every other case.
This function both handles error printing and early/late failures, but it also always returns the actual output of the command
…ions This section of code depends on `rustc_apfloat` rather than our internal types, so this is one potential ICE that we should be able to melt now. This also fixes some missing range and match handling in `rustc_middle`.
…, r=Nadrieril Replace `f16` and `f128` pattern matching stubs with real implementations This section of code depends on `rustc_apfloat` rather than our internal types, so this is one potential ICE that we should be able to melt now. r? `@Nadrieril`
…nieu Add `f16` inline ASM support for 32-bit ARM Adds `f16` inline ASM support for 32-bit ARM. SIMD vector types are taken from [here](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:``@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A32]).`` Relevant issue: rust-lang#125398 Tracking issue: rust-lang#116909 ``@rustbot`` label +F-f16_and_f128
…=compiler-errors
Add `#[rustc_dump_{predicates,item_bounds}]`
Conflicts with rust-lang#126668.
As discussed
r? compiler-errors CC ```@fee1-dead```
Fix `...` in multline code-skips in suggestions When we have long code skips, we write `...` in the line number gutter. For suggestions, we were "centering" the `...` with the line, but that was inconsistent with what we do in every other case *and* off-center.
…nur-ozkan Bootstrap command refactoring: refactor `BootstrapCommand` (step 1) This PR is a first step towards https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap. It refactors `BoostrapCommand` to get it closer to a state where it is an actual command wrapper that can be routed through a central place of command execution, and also to make the distinction between printing output vs handling output programatically clearer (since now it's a mess). The existing usages of `BootstrapCommand` are complicated primarily because of different ways of handling output. There are commands that: 1) Want to eagerly print stdout/stderr of the executed command, plus print an error message if the command fails (output mode `PrintAll`). Note that this error message attempts to print stdout/stderr of the command when `-v` is enabled, but that will always be empty, since this mode uses `.status()` and not `.output()`. 2) Want to eagerly print stdout/stderr of the executed command, but do not print any additional error message if it fails (output mode `PrintOutput`) 3) Want to capture stdout/stderr of the executed command, but print an error message if it fails (output mode `PrintFailure`). This means that the user wants to either ignore the output or handle it programatically, but that's not obvious from the name. The difference between 1) and 2) (unless explicitly specified) is determined dynamically based on the bootstrap verbosity level. It is very difficult for me to wrap my head around all these modes. I think that in a future PR, we should split these axes into e.g. this: 1) Do I want to handle the output programmatically or print it to the terminal? This should be a separate axis, true/false. (Note that "hiding the output" essentially just means saying that I handle it programmatically, and then I ignore the output). 2) Do I want to print a message if the command fails? Yes/No/Based on verbosity (which would be the default). Then there is also the failure mode, but that is relatively simple to handle, the command execution will just shutdown bootstrap (either eagerly or late) when the command fails. Note that this is just a first refactoring steps, there are a lot of other things to be done, so some things might not look "final" yet. The next steps are (not necessarily in this order): - Remove `run` and `run_cmd` and implement everything in terms of `run_tracked` and rename `run_tracked` to `run` - Implement the refactoring specified above (change how output modes work) - Modify `BootstrapCmd` so that it stores `Command` instead of `&mut Command` and remove all the annoying `BootstrapCmd::from` by changing `Command::new` to `BootstrapCmd::new` - Refactor the rest of command executions not currently using `BootstrapCmd` that can access Builder to use the correct output and failure modes. This will include passing Builder to additional places. - Handle the most complex cases, such as output streaming. That will probably need to be handled separately. - Refactor the rest of commands that cannot access builder (e.g. `Config::parse`) by introducing a new command context that will be passed to these places, and then stored in `Builder`. Move certain fields (such as `fail_fast`) from `Builder` to the command context. - Handle the co-operation of `Builder`, `Build`, `Config` and command context. There are some fields and logic used during command execution that are distributed amongst `Builder/Build/Config`, so it will require some refactoring to make it work if the execution will happen on a separate place (in the command context). - Refactor logging of commands, so that it is either logged to a file or printed in a nice hierarchical way that cooperates with the `Step` debug hierarchical output. - Implement profiling of commands (add command durations to the command log, print a log of slowest commands and their execution counts at the end of bootstrap execution, perhaps store command executions to `metrics.json`). - Implement caching of commands. - Implement testing of commands through snapshot tests/mocking. Best reviewed commit by commit. r? ```@onur-ozkan```
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
f16andf128pattern matching stubs with real implementations #123088 (Replacef16andf128pattern matching stubs with real implementations)f16inline ASM support for 32-bit ARM #126555 (Addf16inline ASM support for 32-bit ARM)#[rustc_dump_{predicates,item_bounds}]#126686 (Add#[rustc_dump_{predicates,item_bounds}])...in multline code-skips in suggestions #126723 (Fix...in multline code-skips in suggestions)BootstrapCommand(step 1) #126731 (Bootstrap command refactoring: refactorBootstrapCommand(step 1))r? @ghost
@rustbot modify labels: rollup
Create a similar rollup