Add cfg_select! formatting rules to the style guide - #160967
Conversation
traviscross
added
the
T-style
|
Some changes occurred in src/doc/style-guide cc @rust-lang/style |
rustbot
added
the
S-waiting-on-review
|
|
…matting, r=jieyouxu rustfmt: restrict `cfg_select!` formatting to the `nightly` release channel Closes: rust-lang#160944 `cfg_select!` formatting was implemented in rust-lang#154202. The formatting diverged from what was outlined in the original Style FCP (rust-lang/style-team#201 (comment) and rust-lang#144323 (comment)). Since the 1.99 beta is scheduled to branch from main on August 14 I want to get this nightly formatting gate out so that we can correct the formatting issues before we promote the formatting to the beta / stable release channels. Style Guide PR: rust-lang#160967 r? @jieyouxu cc: @traviscross
Rollup merge of #160998 - ytmimi:nightly_only_cfg_select_formatting, r=jieyouxu rustfmt: restrict `cfg_select!` formatting to the `nightly` release channel Closes: #160944 `cfg_select!` formatting was implemented in #154202. The formatting diverged from what was outlined in the original Style FCP (rust-lang/style-team#201 (comment) and #144323 (comment)). Since the 1.99 beta is scheduled to branch from main on August 14 I want to get this nightly formatting gate out so that we can correct the formatting issues before we promote the formatting to the beta / stable release channels. Style Guide PR: #160967 r? @jieyouxu cc: @traviscross
| If a predicate of the form `name = "value"` does not fit on one line, break | ||
| before the `=`. Block-indent the continuation line once. After this break, use a | ||
| block for the body. Put the `=>` and the opening brace together on a new line, | ||
| at the same indent as the arm: | ||
|
|
||
| ```rust | ||
| cfg_select! { | ||
| // Assume that the following predicate does not fit in the max width. | ||
| feature | ||
| = "an-extremely-long-and-unwieldy-feature-name" | ||
| => { | ||
| ... | ||
| } | ||
| _ => {} | ||
| } | ||
| ``` |
There was a problem hiding this comment.
In addition to name = "value" could a user also write name = some_macro_call_that_expands_to_value!()? Would it still be written like:
cfg_select! {
// Assume that the following predicate does not fit in the max width.
feature
= some_macro_call_that_expands_to_feature_name!(arg1, arg2, arg3)
=> {
...
}
_ => {}
}What if the macro call wraps?
cfg_select! {
// Assume that the following predicate does not fit in the max width.
feature
= some_macro_call_that_expands_to_feature_name!(
arg1,
arg2,
arg3
)
=> {
...
}
_ => {}
}There was a problem hiding this comment.
Thanks. Great question. I've added text and examples to cover this.
| Write the body as an expression, without braces around it, if and only if all of | ||
| the following are true: | ||
|
|
||
| - The body is a single expression. |
There was a problem hiding this comment.
Are block expressions like unsafe {} considered to be singe expressions? I think so based on the earlier sentence:
In this section, block means a plain block expression that has no label and no keyword (such as
unsafe) before it.
Might be good to have some examples with either unsafe {} or async {}.
There was a problem hiding this comment.
Thanks. Done. And I clarified the text a bit further.
| Use braces as the delimiters of the invocation. In item and statement position, | ||
| do not put a semicolon after the closing brace. |
There was a problem hiding this comment.
Does this mean that formatters should always transform cfg_select!() and cfg_select![] into cfg_select! {}?
There was a problem hiding this comment.
Yes. I've made this explicit in the text. Thanks.
| Put the `=>` on the same line as the end of the predicate. If the body is a | ||
| block, put the opening brace of the block on the same line as the `=>`. If the | ||
| `=>` and the brace do not fit there, put them together at the start of a new | ||
| line. Put that line at the same indent as the arm. Never end a line with the | ||
| `=>`. Never put the `=>` and the opening brace of a block body on different | ||
| lines. |
There was a problem hiding this comment.
If we're able to fit the entire predicate function on one line, but the => + { can't fit is this the right cfg_select! formatting:
cfg_select! {
any(one, two, three, four, five, six, seven)
=> {
...
}
}There was a problem hiding this comment.
Thanks; great question. I've added rules and examples to cover this. Please let me know if there are any remaining questions there.
112494c to
226ed87
Compare
|
Not sure if we need to update any rules based on this issue that was reported in rustfmt rust-lang/rustfmt#7045 |
We stabilized `cfg_select!` in Rust 1.95 but haven't yet stabilized formatting support. Let's add formatting rules for it to the style guide.
226ed87 to
0ee198b
Compare
Thanks for pointing that out. Interesting case. I've updated the text to address this. It keeps the |
4 participants
We stabilized
cfg_select!in Rust 1.95 but haven't yet stabilized formatting support. Let's add formatting rules for it to the style guide.Our original FCP was in rust-lang/style-team#201 (comment) inclusive of #144323 (comment).
This PR extends those decisions with handling of more edge cases.
See also:
rustfmtformatting ofcfg_select!pending for Rust 1.99 diverges from style FCP #160944r? @joshtriplett
cc @rust-lang/style @rust-lang/rustfmt