Allow also allow literals as first item of single line let chain#6492
Allow also allow literals as first item of single line let chain#6492ytmimi merged 1 commit intorust-lang:masterfrom
Conversation
|
@calebcartwright @joshtriplett I found this suggestion when I read over rust-lang/rust#110568 (comment) . From what I can tell, it is consensus of the style team to allow also literals (outside of bool literals, no literal is really valid here). |
|
@est31 Confirmed; we don't want to put |
src/pairs.rs
Outdated
| fn is_ident_or_lit(expr: &ast::Expr) -> bool { | ||
| match &expr.kind { | ||
| ast::ExprKind::Path(None, path) if path.segments.len() == 1 => true, | ||
| ast::ExprKind::Lit(_) => true, |
There was a problem hiding this comment.
Let's make the match more explicit for bool literals.
There was a problem hiding this comment.
type checking would reject any literal that's not a bool literal, but shrug, changed it.
There was a problem hiding this comment.
rustfmt operates at an earlier stage of compilation, so if it parses and could be in the AST then we need to be mindful of that.
src/pairs.rs
Outdated
| } | ||
|
|
||
| fn is_ident(expr: &ast::Expr) -> bool { | ||
| fn is_ident_or_lit(expr: &ast::Expr) -> bool { |
There was a problem hiding this comment.
nit: I think we should be more explicit about bool literals.
| fn is_ident_or_lit(expr: &ast::Expr) -> bool { | |
| fn is_ident_or_bool_lit(expr: &ast::Expr) -> bool { |
Might even be helpful to link to text from the style guide explaining the rules if they've been codified yet.
There was a problem hiding this comment.
they have not been codified yet, all there is to link is discussion threads :).
There was a problem hiding this comment.
All good then. No need to link to discussions.
indeed they are, and this PR is one of the things I am doing to get them stabilized: to get all open questions resolved around formatting. |
ytmimi
left a comment
There was a problem hiding this comment.
Thanks for making those changes.
|
Just ran our Diff-Check job. Looks like there will be two clippy test cases that'll change once we sync these changes with Diff in /tmp/rust-lang-rust-W6U1GxGa/src/tools/clippy/tests/ui/needless_late_init.rs:246:
}
let x;
- if true
- && let Some(n) = Some("let chains too")
- {
+ if true && let Some(n) = Some("let chains too") {
x = 1;
} else {
x = 2;Diff in /tmp/rust-lang-rust-W6U1GxGa/src/tools/clippy/tests/ui/needless_if.rs:46:
if let true = true
&& true
{}
- if true
- && let true = true
- {}
+ if true && let true = true {}
// Can lint nested `if let`s
if {
//~^ needless_if |
…bool-lit, r=calebcartwright rustfmt: Also allow bool literals as first item of let chain This is a functional cherry-pick of rust-lang/rustfmt#6492 I'm bringing this change over directly as the subtree sync is taking more effort than anticipated (some unrelated r-l/rustfmt changes need to be reverted before we perform the full sync) and we need to ensure that rustfmt behavior accounts with the final style guide rules as part of let chain stabilization. r? `@ghost`
…bool-lit, r=calebcartwright rustfmt: Also allow bool literals as first item of let chain This is a functional cherry-pick of rust-lang/rustfmt#6492 I'm bringing this change over directly as the subtree sync is taking more effort than anticipated (some unrelated r-l/rustfmt changes need to be reverted before we perform the full sync) and we need to ensure that rustfmt behavior accounts with the final style guide rules as part of let chain stabilization. r? ``@ghost``
…bool-lit, r=calebcartwright rustfmt: Also allow bool literals as first item of let chain This is a functional cherry-pick of rust-lang/rustfmt#6492 I'm bringing this change over directly as the subtree sync is taking more effort than anticipated (some unrelated r-l/rustfmt changes need to be reverted before we perform the full sync) and we need to ensure that rustfmt behavior accounts with the final style guide rules as part of let chain stabilization. r? ```@ghost```
…bool-lit, r=calebcartwright rustfmt: Also allow bool literals as first item of let chain This is a functional cherry-pick of rust-lang/rustfmt#6492 I'm bringing this change over directly as the subtree sync is taking more effort than anticipated (some unrelated r-l/rustfmt changes need to be reverted before we perform the full sync) and we need to ensure that rustfmt behavior accounts with the final style guide rules as part of let chain stabilization. r? ````@ghost````
Rollup merge of rust-lang#140486 - calebcartwright:rustfmt-let-chain-bool-lit, r=calebcartwright rustfmt: Also allow bool literals as first item of let chain This is a functional cherry-pick of rust-lang/rustfmt#6492 I'm bringing this change over directly as the subtree sync is taking more effort than anticipated (some unrelated r-l/rustfmt changes need to be reverted before we perform the full sync) and we need to ensure that rustfmt behavior accounts with the final style guide rules as part of let chain stabilization. r? ````@ghost````
… r=calebcartwright rustfmt: Also allow bool literals as first item of let chain This is a functional cherry-pick of rust-lang/rustfmt#6492 I'm bringing this change over directly as the subtree sync is taking more effort than anticipated (some unrelated r-l/rustfmt changes need to be reverted before we perform the full sync) and we need to ensure that rustfmt behavior accounts with the final style guide rules as part of let chain stabilization. r? ````@ghost````
Also allow literals as the first item in a single line let chain, not just idents. This will most probably not occur in most real-world code, but it makes things a little bit more consistent. While rustfmt allows any literal type, like also string literals, those will not create valid rust code. Only bool literals will.
Implements suggestion from rust-lang/rust#110568 (comment) .