-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 13 pull requests #120743
Closed
Closed
Rollup of 13 pull requests #120743
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
The new flag has been described in the Major Change Proposal at rust-lang/compiler-team#707
…more projections.
This makes it possible for two nodes/edges in the coverage graph to share the same counter, without causing the instrumentor to inject unwanted duplicate counter-increment statements.
Co-authored-by: Ralf Jung <post@ralfj.de>
When encountering an `if let` tail expression without an `else` arm for an enum with a single variant, suggest writing an irrefutable `let` binding instead. ``` error[E0317]: `if` may be missing an `else` clause --> $DIR/irrefutable-if-let-without-else.rs:8:5 | LL | fn foo(x: Enum) -> i32 { | --- expected `i32` because of this return type LL | / if let Enum::Variant(value) = x { LL | | value LL | | } | |_____^ expected `i32`, found `()` | = note: `if` expressions without `else` evaluate to `()` = help: consider adding an `else` block that evaluates to the expected type help: consider using an irrefutable `let` binding instead | LL ~ let Enum::Variant(value) = x; LL ~ value | ``` Fix rust-lang#61788.
Ignoring unused bindings should be a determination made by a human, `rustfix` shouldn't auto-apply the suggested change. Fix rust-lang#54196.
It's never used.
When `download-ci-llvm` is enabled, `llvm_out` ends up with the error below due to an incorrect path on cross-compilations. This change fixes that. ``` failed to execute command: "/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--version" ERROR: No such file or directory (os error 2) ``` Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
When `catch_fatal_errors` catches a `FatalErrorMarker`, it returns an `ErrorGuaranteed` that is conjured out of thin air with `unchecked_claim_error_was_emitted`. But that `ErrorGuaranteed` is never used. This commit changes it to instead conjure a `FatalError` out of thin air. (A non-deprecated action!) This makes more sense because `FatalError` and `FatalErrorMarker` are a natural pairing -- a `FatalErrorMarker` is created by calling `FatalError::raise`, so this is effectively getting back the original `FatalError`. This requires a tiny change in `catch_with_exit_code`. The old result of the `catch_fatal_errors` call there was `Result<Result<(), ErrorGuaranteed>, ErrorGuaranteed>` which could be `flatten`ed into `Result<(), ErrorGuaranteed>`. The new result of the `catch_fatal_errors` calls is `Result<Result<(), ErrorGuaranteed>, FatalError>`, which can't be `flatten`ed but is still easily matched for the success case.
By making non-unicode arguments a fatal error instead of a warning, we don't need to handle what comes after, which avoids the need for an `unchecked_claim_error_was_emitted` call.
`main_args` calls `from_matches`, which does lots of initialization. If anything goes wrong, `from_matches` emits an error message and returns `Err(1)` (or `Err(3)`). `main_args` then turns the `Err(1)` into `Err(ErrorGuaranteed)`, because that's what `catch_with_exit_code` requires on error. But `catch_with_exit_code` doesn't do anything with the `ErrorGuaranteed`, it just exits with `EXIT_FAILURE`. We can avoid the creation of the `ErrorGuaranteed` (which requires an undesirable `unchecked_claim_error_was_emitted` call), by changing `from_matches` to instead eagerly abort if anything goes wrong. The behaviour from the user's point of view is the same: an early abort with an `EXIT_FAILURE` exit code. And we can also simplify `from_matches` to return an `Option` instead of a `Result`: - Old `Err(0)` case --> `None` - Old `Err(_)` case --> fatal error. This requires similar changes to `ScrapeExamplesOptions::new` and `load_call_locations`.
- In `emit_producing_error_guaranteed`, only allow `Level::Error`. - In `emit_diagnostic`, only produce `ErrorGuaranteed` for `Level` and `DelayedBug`. (Not `Bug` or `Fatal`. They don't need it, because the relevant `emit` methods abort.) - Add/update various comments.
…teed`. It's more to-the-point.
Add armv8r-none-eabihf target for the Cortex-R52.
…illot Add FileCheck annotations to MIR-opt SROA tests Part of rust-lang#116971, adds FileCheck annotations to SROA MIR-opt tests in `tests/mir-opt/sroa` and a few uncategorized files. r? cjgillot
…rrors Mark "unused binding" suggestion as maybe incorrect Ignoring unused bindings should be a determination made by a human, `rustfix` shouldn't auto-apply the suggested change. Fix rust-lang#54196.
Suggest turning `if let` into irrefutable `let` if appropriate When encountering an `if let` tail expression without an `else` arm for an enum with a single variant, suggest writing an irrefutable `let` binding instead. ``` error[E0317]: `if` may be missing an `else` clause --> $DIR/irrefutable-if-let-without-else.rs:8:5 | LL | fn foo(x: Enum) -> i32 { | --- expected `i32` because of this return type LL | / if let Enum::Variant(value) = x { LL | | value LL | | } | |_____^ expected `i32`, found `()` | = note: `if` expressions without `else` evaluate to `()` = help: consider adding an `else` block that evaluates to the expected type help: consider using an irrefutable `let` binding instead | LL ~ let Enum::Variant(value) = x; LL ~ value | ``` Fix rust-lang#61788.
coverage: Split out counter increment sites from BCB node/edge counters This makes it possible for two nodes/edges in the coverage graph to share the same counter, without causing the instrumentor to inject unwanted duplicate counter-increment statements. --- ```@rustbot``` label +A-code-coverage
…rrors pattern_analysis: gather up place-relevant info We track 3 things about each place during exhaustiveness: its type, its (data) validity, and whether it's the scrutinee place. This PR gathers all three into a single struct. r? ````@compiler-errors````
…rcote Add parallel rustc ui tests Updates rust-lang#118698 Add some ui tests for parallel rustc front end This is a relatively large feature so I think it's worth creating a new entity in tests/ui folder, so we need to modify the limit in tidy.
…cross-target, r=albertlarsan68 fix `llvm_out` to use the correct LLVM root When `download-ci-llvm` is enabled, `llvm_out` ends up with the error below due to an incorrect path on cross-compilations. This change fixes that. ```sh failed to execute command: "/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--version" ERROR: No such file or directory (os error 2) ```
…crum Don't use bashism in checktools.sh `if [[` doesn't work because this is a `/bin/sh` script. We were never running the success side of this `if` at all.
MirPass: make name more const Continues rust-lang#120161, this time applied to `MirPass` instead of `MirLint`, locally shaves few (very few) instructions off. r? `@cjgillot`
…ms, r=oli-obk Remove some `unchecked_claim_error_was_emitted` calls We want to drive the number of these calls down as much as possible. This PR gets rid of a bunch of them. r? `@oli-obk`
rustbot
added
A-testsuite
Area: The testsuite used to check the correctness of rustc
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)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
Feb 7, 2024
@bors r+ rollup=never p=5 |
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
Feb 7, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 7, 2024
Rollup of 13 pull requests Successful merges: - rust-lang#110482 (Add armv8r-none-eabihf target for the Cortex-R52.) - rust-lang#119162 (Add unstable `-Z direct-access-external-data` cmdline flag for `rustc`) - rust-lang#120302 (various const interning cleanups) - rust-lang#120455 ( Add FileCheck annotations to MIR-opt SROA tests) - rust-lang#120470 (Mark "unused binding" suggestion as maybe incorrect) - rust-lang#120479 (Suggest turning `if let` into irrefutable `let` if appropriate) - rust-lang#120564 (coverage: Split out counter increment sites from BCB node/edge counters) - rust-lang#120633 (pattern_analysis: gather up place-relevant info) - rust-lang#120664 (Add parallel rustc ui tests) - rust-lang#120721 (fix `llvm_out` to use the correct LLVM root) - rust-lang#120726 (Don't use bashism in checktools.sh) - rust-lang#120733 (MirPass: make name more const) - rust-lang#120735 (Remove some `unchecked_claim_error_was_emitted` calls) Failed merges: - rust-lang#120727 (exhaustiveness: Prefer "`0..MAX` not covered" to "`_` not covered") r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Feb 7, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-testsuite
Area: The testsuite used to check the correctness of rustc
rollup
A PR which is a rollup
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)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
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:
-Z direct-access-external-data
cmdline flag forrustc
#119162 (Add unstable-Z direct-access-external-data
cmdline flag forrustc
)if let
into irrefutablelet
if appropriate #120479 (Suggest turningif let
into irrefutablelet
if appropriate)llvm_out
to use the correct LLVM root #120721 (fixllvm_out
to use the correct LLVM root)unchecked_claim_error_was_emitted
calls #120735 (Remove someunchecked_claim_error_was_emitted
calls)Failed merges:
0..MAX
not covered" to "_
not covered" #120727 (exhaustiveness: Prefer "0..MAX
not covered" to "_
not covered")r? @ghost
@rustbot modify labels: rollup
Create a similar rollup