| Age | Commit message (Collapse) | Author | Lines |
|---|
|
style-guide: Organizational and editing tweaks (no semantic changes)
I'd recommend reviewing this PR commit-by-commit; each commit is self-contained
and should be easy to review at a glance.
- style-guide: Move text about block vs visual indent to indentation section
- style-guide: Move and expand text about trailing commas
- style-guide: s/right-ward/rightward/
- style-guide: Consistently refer to rustfmt as `rustfmt`
- style-guide: Remove inaccurate statement about rustfmt
- style-guide: Define (and capitalize) "ASCIIbetically"
- style-guide: Update cargo.md for authors being optional and not recommended
- style-guide: Avoid normative recommendations for formatting tool configurability
- style-guide: Clarify advice on names matching keywords
- style-guide: Reword an awkwardly phrased recommendation (and fix a typo)
- style-guide: Rephrase a confusingly ordered, ambiguous sentence (and fix a typo)
- style-guide: Avoid hyphenating "semicolon"
- style-guide: Make link text in SUMMARY.md match the headings in the linked pages
- style-guide: Define what an item is
- style-guide: Avoid referring to the style team in the past tense
|
|
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.
|
|
We live!
|
|
|
|
|
|
|
|
This sentence had a parenthetical without a closing parenthesis, and had
the phrase "which doesn't require special formatting" ambiguously at the
end of a list when it only applied to the last item of the list.
|
|
|
|
In particular, specify what this advice is an alternative to (creative
misspellings such as `krate`).
|
|
It's not within the scope of the style guide to tell formatting tools
whether, or how, to allow configurability of non-default formatting.
|
|
Change an example using the authors field to use a long feature list instead.
Change the conventions for the authors field to say "if present".
|
|
The style guide didn't give any definition for it.
|
|
rustfmt does include a mechanism to distinguish standard library
imports, which it does syntactically by crate name. Avoid making a
misleading statement that implies it cannot do this.
|
|
|
|
We already use the word "rightward" elsewhere; avoid the unnecessarily
hyphenated "right-ward".
|
|
`principles.md` includes some high-level guiding principles for
formatting, but also includes a few specific formatting provisions.
While those provisions apply in many places, the same holds true for
other high-level guidance. Move the text about trailing commas to
`README.md`, so that `principles.md` can focus on guiding principles
while the top level of the style guide gives concrete formatting
recommendations.
|
|
`principles.md` includes some high-level guiding principles for
formatting, but also includes a few specific formatting provisions.
While those provisions apply in many places, the same holds true for
other high-level guidance, such as the indentation section. Move the
text about using block indent rather than visual indent to the
indentation section, so that `principles.md` can focus on guiding
principles while the top level of the style guide gives concrete
formatting recommendations.
|
|
"does done fit" should have been "does not fit".
|
|
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.
|
|
Co-authored-by: Michael Goulet <michael@errs.io>
|
|
* incompatibilities
* invocation
* keywords
* nonexistent
* shakespeare
* the
* toolchain
* transparent
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
Toml now uses [toml.io](https://toml.io) for released specifications
and the github repo for development. Also the old link was for the 0.4
specification, while cargo uses toml_edit, which uses toml 1.0
(reference:
https://github.com/toml-rs/toml/blob/main/crates/toml_edit/CHANGELOG.md#030---2021-09-13).
Finally the discussion of "Bare keys" vs "Quoted keys" has moved from
the `#table` section to `#keys`.
|
|
|
|
|
|
|
|
|
|
Per [RFC 3309](https://rust-lang.github.io/rfcs/3309-style-team.html).
|
