gate let_chains in all places before the 2024 edition#140198
gate let_chains in all places before the 2024 edition#140198fee1-dead wants to merge 1 commit intorust-lang:masterfrom
let_chains in all places before the 2024 edition#140198Conversation
Since `let_chains` relies on the 2024 edition drop order to be consistent, it makes sense for us to gate it in all places, even when there are unstable features such as with `if_let_guard`s in matches. This removes the need for us to pass in an enum to `CondChecker` as we can just always pass in the edition instead.
|
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
| = help: add `#![feature(let_chains)]` to the crate attributes to enable | ||
| = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date | ||
|
|
||
| error[E0658]: `let` expressions in this position are unstable |
There was a problem hiding this comment.
Is this fine in the 2024 edition? If so it should say that rather than it being unstable.
There was a problem hiding this comment.
It's due to the way #132833 was done: it just exempted 2024 usages from the feature gate instead of stabilizing the feature gate and adding an edition dependent error. I left that for future work, as I didn't know when it would stabilize. Plus, I saw that a lot of compiler crates were using let chains and I didn't want to play catch up with all the #![feature(let_chains)] changes happening that occur as the compiler does changes naturally (knowing that the stabilization would likely take months).
|
Same goes for |
|
@rustbot labels +I-lang-nominated Let's vibe check on the lang call the direction we want to go here. |
|
@rustbot labels -I-lang-nominated We discussed this today. Our general policy is to prefer consistency between editions over consistency within an edition, so our appetite was in favor of allowing what can be allowed in older editions. We should of course ensure the diagnostics in the older editions are helpful in mitigating the surprise this may cause, e.g. by having the errors note when something needs an edition bump. The stabilizations for this will of course need our FCP. |
|
Appears to be unnecessary |
Since
let_chainsrelies on the 2024 edition drop order to be consistent, it makes sense for us to gate it in all places, even when there are unstable features such as withif_let_guards in matches. This removes the need for us to pass in an enum toCondCheckeras we can just always pass in the edition instead.cc @est31