style-guide: Remove material about tool configurability

The style guide discusses the default Rust style. Configurability of
Rust formatting tools are not the domain of the style guide.
This commit is contained in:
Josh Triplett 2023-06-28 15:15:22 -07:00
parent e2a7ba2771
commit 715efa418e
4 changed files with 2 additions and 46 deletions

View File

@ -40,7 +40,6 @@ options.
* Each level of indentation must be four spaces (that is, all indentation
outside of string literals and comments must be a multiple of four).
* The maximum width for a line is 100 characters.
* A tool may choose to make some of these configurable.
#### Block indent
@ -99,8 +98,6 @@ fn bar() {}
fn baz() {}
```
Formatting tools may wish to make the bounds on blank lines configurable.
### [Module-level items](items.md)
### [Statements](statements.md)
### [Expressions](expressions.md)
@ -231,10 +228,6 @@ complexity of an item (for example, that all components must be simple names,
not more complex sub-expressions). For more discussion on suitable heuristics,
see [this issue](https://github.com/rust-lang-nursery/fmt-rfcs/issues/47).
Tools should give the user an option to ignore such heuristics and always use
the normal formatting.
## [Non-formatting conventions](advice.md)
## [Cargo.toml conventions](cargo.md)

View File

@ -814,8 +814,7 @@ let arr = [combinable(
)];
```
Such behaviour should extend recursively, however, tools may choose to limit the
depth of nesting.
Such behaviour should extend recursively.
Only where the multi-line sub-expression is a closure with an explicit block,
this combining behaviour may be used where there are other arguments, as long as
@ -852,9 +851,6 @@ compound expression, then use parentheses around it, e.g., `..(x + 1)`,
Hexadecimal literals may use upper- or lower-case letters, but they must not be
mixed within the same literal. Projects should use the same case for all
literals, but we do not make a recommendation for either lower- or upper-case.
Tools should have an option to convert mixed case literals to upper-case, and
may have an option to convert all literals to either lower- or upper-case.
## Patterns

View File

@ -15,9 +15,6 @@ alphabetically. When sorting, `self` and `super` must come before any other
names. Module declarations should not be moved if they are annotated with
`#[macro_use]`, since that may be semantics changing.
Tools should make the above ordering optional.
### Function definitions
In Rust, people often find functions by searching for `fn [function-name]`, so
@ -372,33 +369,6 @@ where
+ Index<RangeToInclusive<Idx>, Output = Self::Output> + Index<RangeFull>
```
#### Option - `where_single_line`
`where_single_line` is `false` by default. If `true`, then a where clause with
exactly one component may be formatted on a single line if the rest of the
item's signature is also kept on one line. In this case, there is no need for a
trailing comma and if followed by a block, no need for a newline before the
block. E.g.,
```rust
// May be single-lined.
fn foo<T>(args) -> ReturnType
where T: Bound {
body
}
// Must be multi-lined.
fn foo<T>(
args
) -> ReturnType
where
T: Bound,
{
body
}
```
### Type aliases
Type aliases should generally be kept on one line. If necessary to break the
@ -458,7 +428,7 @@ use a::b::{foo, bar, baz};
#### Large list imports
Prefer to use multiple imports rather than a multi-line import. However, tools
should not split imports by default (they may offer this as an option).
should not split imports by default.
If an import does require multiple lines (either because a list of single names
does not fit within the max width, or because of the rules for nested imports

View File

@ -120,9 +120,6 @@ following are true:
let Some(1) = opt else { return };
```
Formatters may allow users to configure the value of the threshold
used to determine whether a let-else statement is *short*.
Otherwise, the let-else statement requires some line breaks.
If breaking a let-else statement across multiple lines, never break between the