| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Amend style guide section for formatting where clauses in type aliases
This PR has two parts:
1. Amend wording about breaking before or after the `=`, which is a style guide bugfix to align it with current rustfmt behavior.
2. Explain how to format trailing (#89122) where clauses, which are preferred in both GATs (#90076) and type aliases (#114662).
r? `@joshtriplett`
|
|
style-guide: Document formatting of `as` casts (mostly like a binary operator)
`as` casts currently get formatted like a binary operator, except that
the second line can stack several `as` casts rather than breaking them
each onto their own line. Document this.
As far as I can tell (cc `@calebcartwright` for verification), this is not a 2024 edition change, it just documents current behavior.
|
|
style-guide: Add section on bugs, and resolving bugs
|
|
|
|
|
|
|
|
|
|
`as` casts currently get formatted like a binary operator, except that
the second line can stack several `as` casts rather than breaking them
each onto their own line. Merge `as` into a subsection of the binary
operators section, and then go into detail on the one difference between
`as` formatting and binary operator formatting.
|
|
Improve the rust style guide doc
- Make the levels of headings consistent in this whole document.
Before this change, the highest level of headings in some file is level 1, but in most of the files the that is level 2. Not consistent.
- Fix some headings
- Follow the markdown linter advices
- Remove redundant empty lines
- Surround each heading with empty lines
- Use the same symbol for different levels of unordered list entries
|
|
style-guide: Document style editions, start 2024 style edition
Link to a snapshot for the 2015/2018/2021 style edition.
This is a draft, because I'd like to wait for a few style guide fixes to merge
before snapshotting the 2015/2018/2021 style edition:
- https://github.com/rust-lang/rust/pull/113145
- https://github.com/rust-lang/rust/pull/113380
- https://github.com/rust-lang/rust/pull/113384
- https://github.com/rust-lang/rust/pull/113385
- https://github.com/rust-lang/rust/pull/113386
- https://github.com/rust-lang/rust/pull/113392
I'd like to wait for these for two reasons: to make it easier to see the
differences between the 2015/2018/2021 style edition and the 2024 style
edition (without the noise of guide-wide changes), and to minimize confusion so
that bugfixes to the style guide that we include in the previous edition don't
look like they're only part of the 2024 style edition.
I've used "Miscellaneous `rustfmt` bugfixes" as a starting point for the list
of 2024 changes, for now. We can update that when we add more 2024 changes.
The section added in this PR can then serve as a baseline for our drafts of
2024 style edition changes.
In the meantime, I'd like to get someone from `@rust-lang/style` to review and
approve the text here; I'll update it with a commit hash when the above PRs
have merged.
|
|
|
|
Link to a snapshot for the 2015/2018/2021 style edition.
|
|
|
|
- Make the levels of headings consistent in this whole document
- Fix some headings
- Remove redundant empty lines
- Follow the markdown linter advices to use the same symbol for different level of unordered list entries
|
|
|
|
|
|
|
|
|
|
Use consistent phrasing, and add an "and".
|
|
Long text without numeric numbers when numeric numbers are used are hard to read.
|
|
|
|
Co-authored-by: Caleb Cartwright <calebcartwright@users.noreply.github.com>
|
|
An example immediately following "Put each bound on its own line." did
not put each bound on its own line.
|
|
|
|
Make it clear the rule for stacking the second line on the first applies
recursively, as long as the condition holds.
|
|
style
The style guide inconsistently used language like "there should be a
space" or "it should be on its own line", or "may be written on a single
line", for things that are required components of the default Rust
style. "should" and especially "may" come across as optional. While the
style guide overall now has a statement at the top that the default
style itself is a *recommendation*, the *definition* of the default
style should not be ambiguous about what's part of the default style.
Rewrite language in the style guide to only use "should" and "may" and
similar for truly optional components of the style (e.g. things a tool
cannot or should not enforce in its default configuration).
In their place, either use "must", or rewrite in imperative style ("put
a space", "start it on the same line"). The latter also substantially
reduces the use of passive voice.
This is a purely editorial change, and does not affect the semantic
definition of the Rust style.
|
|
Avoid putting a sentence fragment after a list; integrate it with the
sentence before the list.
|
|
The style guide requires a trailing comma on where clause components,
but then gives an example that doesn't include one. Add the missing
trailing comma.
|
|
|
|
The style guide discusses the default Rust style. Configurability of
Rust formatting tools are not the domain of the style guide.
|
|
|
|
r=calebcartwright
style-guide: Fix chain example to match rustfmt behavior
The style guide gave an example of breaking a multi-line chain element
and all subsequent elements to a new line, but that same example and the
accompanying text also had several chain items stacked on the first
line. rustfmt doesn't do this, except when the rule saying to combine
```
shrt
.y()
```
into
```
shrt.y()
```
applies.
This is a bugfix to match rustfmt behavior, so it's not a breaking change, and
it just needs a ``@rust-lang/style`` reviewer to r+.
|
|
r=compiler-errors
style-guide: Expand example of combinable expressions to include arrays
Arrays are allowed as combinable expressions, but none of the examples
show that.
|
|
style-guide: Clarify grammar for small patterns (not a semantic change)
The grammar as written feels ambiguous and confusing, in large part
because it uses square brackets and commas in the names of
non-terminals. Rewrite it to avoid symbols in the names of
non-terminals, and to instead wrap terminals in backquotes.
Also rename "smallntp" to "small_no_tuple" to make it self-describing.
|
|
joshtriplett:style-guide-document-assignment-newlines, r=joshtriplett
style-guide: Document newline rules for assignment operators
The style guide gives general rules for binary operators including
assignment, and one of those rules says to put the operator on the
subsequent line; the style guide needs to explicitly state the exception
of breaking *after* assignment operators rather than before.
This is already what rustfmt does and what users do; this fixes the
style guide to match the expected default style.
|
|
Arrays are allowed as combinable expressions, but none of the examples
show that.
|
|
The style guide gave an example of breaking a multi-line chain element
and all subsequent elements to a new line, but that same example and the
accompanying text also had several chain items stacked on the first
line. rustfmt doesn't do this, except when the rule saying to combine
```
shrt
.y()
```
into
```
shrt.y()
```
applies.
|
|
The meaning of "smallntp" was not immediately obvious at a glance.
Rename it to the self-describing "small_no_tuple"
|
|
The grammar as written feels ambiguous and confusing, in large part
because it uses square brackets and commas in the names of
non-terminals. Rewrite it to avoid symbols in the names of
non-terminals, and to instead wrap terminals in backquotes.
|
|
Co-authored-by: Michael Goulet <michael@errs.io>
|
|
|
|
|
|
joshtriplett:style-guide-narrow-dereference-guidance, r=calebcartwright
style-guide: Narrow guidance about references and dereferencing
The style guide advises "prefer dereferencing to taking references", but
doesn't give guidance on when that "preference" should get overridden by
other considerations. Give an example of when it's fine to ignore
that advice.
|
|
joshtriplett:style-guide-example-multi-line-attribute, r=calebcartwright
style-guide: Add an example of formatting a multi-line attribute
We already say to format attributes like functions, but we didn't have
an example of formatting a multi-line attribute.
|
|
The style guide gives general rules for binary operators including
assignment, and one of those rules says to put the operator on the
subsequent line; the style guide needs to explicitly state the exception
of breaking *after* assignment operators rather than before.
This is already what rustfmt does and what users do; this fixes the
style guide to match the expected default style.
|
|
The style guide advises "prefer dereferencing to taking references", but
doesn't give guidance on when that "preference" should get overridden by
other considerations. Give an example of when it's fine to ignore
that advice.
|
|
We already say to format attributes like functions, but we didn't have
an example of formatting a multi-line attribute.
|
|
Give some additional examples with multi-line patterns.
Make it clearer to go on to the next case if the conditions aren't met.
|
|
r=calebcartwright
style-guide: Rewrite let-else section for clarity, without changing formatting
The section as written did not cover all cases, and left some of them
implicit. Rewrite it to systematically cover all cases. Place examples
immediately following the corresponding case.
In the process, reorder to move the simplest cases first: start with
single-line and add progressively more line breaks.
This does not change the meaning of the section at all, and in
particular does not change the defined style for let-else statements.
|
|
joshtriplett:style-guide-defaults-vs-configurability, r=compiler-errors
style-guide: Add language disclaiming any effects on non-default Rust styles
Make it clear that the style guide saying "must" doesn't forbid
developers from doing differently (as though any power on this Earth
could do that) and doesn't forbid tools from allowing any particular
configuration options.
Otherwise, people might wonder (for instance) if there's a semantic difference
between "must" and "should" in the style guide, and whether tools are "allowed"
to offer configurability of something that says "must".
|
