-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
[WIP; Crater] Use parse_cond_expr
instead parse_expr
in if
guards
#74315
Conversation
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
parse_cond_expr
instead parse_expr
in if guards
parse_cond_expr
instead parse_expr
in if
guards
a99f28e
to
2ddb949
Compare
in the case of if guards
I think that the change is correct but I want a crater run in case this affects code out in the wild. @bors try @craterbot check |
⌛ Trying commit a1a3d97 with merge 0ab79c4b48ad19260fa46623f452c1b403a360e8... |
☀️ Try build successful - checks-actions, checks-azure |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
// This function is to check whether `if-let` guard error points to | ||
// `let_chains` feature gate, which is wrong and confuse people. | ||
pub fn foo(a: &[u8], b: bool) -> bool { | ||
match b { | ||
true if let [1, 2, 3, ..] = a => true, |
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.
But it is a subset of "let
chains" (or rather, let
expressions in more positions), at most you should change what feature-gate it points to.
Looking around at the let chains tests, you want all of these cases to emit feature-gate errors:
rust/src/test/ui/rfc-2497-if-let-chains/feature-gate.rs
Lines 111 to 136 in 6ee1b62
fn _macros() { | |
macro_rules! noop_expr { ($e:expr) => {}; } | |
noop_expr!((let 0 = 1)); | |
//~^ ERROR `let` expressions in this position are experimental [E0658] | |
macro_rules! use_expr { | |
($e:expr) => { | |
if $e {} | |
while $e {} | |
} | |
} | |
use_expr!((let 0 = 1 && 0 == 0)); | |
//~^ ERROR `let` expressions in this position are experimental [E0658] | |
//~| ERROR `let` expressions are not supported here | |
//~| ERROR `let` expressions are not supported here | |
use_expr!((let 0 = 1)); | |
//~^ ERROR `let` expressions in this position are experimental [E0658] | |
//~| ERROR `let` expressions are not supported here | |
//~| ERROR `let` expressions are not supported here | |
#[cfg(FALSE)] (let 0 = 1); | |
//~^ ERROR `let` expressions in this position are experimental [E0658] | |
use_expr!(let 0 = 1); | |
//~^ ERROR no rules expected the token `let` | |
// ^--- FIXME(53667): Consider whether `Let` can be added to `ident_can_begin_expr`. | |
} |
Note that noop_expr!
and #[cfg(FALSE)]
must emit feature-gate errors despite those AST nodes never reaching HIR lowering.
I think you should copy that entire test, remove _while
, and then put every if let
in a guard, e.g.:
match () { () if let ... = ... => {} }
parse_cond_expr
instead parse_expr
in if
guardsparse_cond_expr
instead parse_expr
in if
guards
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Closing in favor of #74566. |
Gate if-let guard feature Enhanced on rust-lang#74315. That PR is in crater queue so I don't want to push to it. Close rust-lang#74232 cc rust-lang#51114
This PR improves diagnostic a bit for #15980.