-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add suggestion to remove if in let..else block #107213
Add suggestion to remove if in let..else block #107213
Conversation
r? @eholk (rustbot has picked a reviewer for you, use r? to override) |
cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki |
help: There may be an extra `if` before the `let...else` | ||
--> $DIR/ensure-that-let-else-does-not-interact-with-let-chains.rs:24:5 | ||
| | ||
LL | if let Some(n) = opt else { | ||
| ^^ |
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.
Related test source code: rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs.
This behavior is correct as this hint should only appear when it is ambiguous if the user is try to use an if-let
or an let..else
.
The other two cases that this test handles are:
if let Some(n) = opt && n == 1 else {
//~^ ERROR this `if` expression is missing a block after the condition
return;
};
if let Some(n) = opt && let another = n else {
//~^ ERROR this `if` expression is missing a block after the condition
return;
};
which are less ambiguous.
This also indicates that we don't emit this help on while-let
-- this wasn't in scope of the original issue so I took a conservative approach in this PR.
I can take a look at this tomorrow. |
0a13106
to
e2ea394
Compare
cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki |
312358b
to
f76990e
Compare
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.
This looks pretty good to me as is. Please address nits (or tell me why I'm wrong 😆) and I think this can get r+'d soon.
f76990e
to
e6d7264
Compare
e6d7264
to
94a5325
Compare
Adds an additional hint to failures where we encounter an else keyword while we're parsing an if-let block. This is likely that the user has accidentally mixed if-let and let...else together.
94a5325
to
a8b77cf
Compare
@bors r+ rollup |
…ntal-let-else, r=compiler-errors Add suggestion to remove if in let..else block Adds an additional hint to failures where we encounter an else keyword while we're parsing an if-let expression. This is likely that the user has accidentally mixed if-let and let..else together. Fixes rust-lang#103791.
Rollup of 9 pull requests Successful merges: - rust-lang#105552 (Add help message about function pointers) - rust-lang#106583 (Suggest coercion of `Result` using `?`) - rust-lang#106767 (Allow setting CFG_DISABLE_UNSTABLE_FEATURES to 0) - rust-lang#106823 (Allow fmt::Arguments::as_str() to return more Some(_).) - rust-lang#107166 (rustc_metadata: Support non-`Option` nullable values in metadata tables) - rust-lang#107213 (Add suggestion to remove if in let..else block) - rust-lang#107223 (`sub_ptr()` is equivalent to `usize::try_from().unwrap_unchecked()`, not `usize::from().unwrap_unchecked()`) - rust-lang#107227 (`new_outside_solver` -> `evaluate_root_goal`) - rust-lang#107232 (rustdoc: simplify settings popover DOM, CSS, JS) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
IfExpressionMissingThenBlockSub, InvalidBlockMacroSegment, InvalidComparisonOperator, | ||
InvalidComparisonOperatorSub, InvalidInterpolatedExpression, InvalidLiteralSuffixOnTupleIndex, | ||
InvalidLogicalOperator, InvalidLogicalOperatorSub, LabeledLoopInBreak, LeadingPlusNotSupported, | ||
LeftArrowOperator, LifetimeInBorrowExpression, MacroInvocationWithQualifiedPath, |
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.
This is horrible noise. Can't one instead use crate::errors::ErrorName
instead all over the file? I'm asking this as a general pattern.
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.
Alternatively, let's replace this with a glob import
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.
Note: this is nothing that this particular PR has caused. The pattern of having a giant use at the top just creates this noise in PRs like this.
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.
Let's discuss it on zulip.
…nd-2, r=estebank Make the "extra if in let...else block" hint a suggestion Changes the hint to a suggestion, suggested in rust-lang#107213. r? `@estebank`
…nd-2, r=estebank Make the "extra if in let...else block" hint a suggestion Changes the hint to a suggestion, suggested in rust-lang#107213. r? ``@estebank``
…nd-2, r=estebank Make the "extra if in let...else block" hint a suggestion Changes the hint to a suggestion, suggested in rust-lang#107213. r? ```@estebank```
Adds an additional hint to failures where we encounter an else keyword while we're parsing an if-let expression.
This is likely that the user has accidentally mixed if-let and let..else together.
Fixes #103791.