mirror of
https://github.com/rust-lang/rust.git
synced 2025-05-14 02:49:40 +00:00
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:
parent
e2a7ba2771
commit
715efa418e
@ -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)
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user