| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
I'm going to make a follow-up PR shortly linking from rust-lang/rust to the dev guide so this info isn't duplicated.
|
|
mostly this just suggests using a tracking issue instead of inlining the info from the issue template
|
|
|
|
|
|
|
|
Splitting the two was confusing and meant that similar information was in wildly different parts of the guide. Combine them into a single page.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
This complements the existing `aarch64-unknown-linux-ohos` and
`armv7-unknown-linux-ohos` targets.
|
|
|
|
doc: loongarch: Update maintainers
My colleague, `@zhaixiaojuan,` has been completely occupied with other matters and is no longer in charge of Rust. Consequently, I intend to update the maintainers in the platform documentation to avoid causing any disruptions for her and to ensure that relevant notifications regarding LoongArch are promptly directed to the appropriate developers.
Thanks your for contributions!
|
|
Add esp-idf missing targets
Adds some esp-idf missing targets to the table
|
|
Add support for NetBSD/aarch64-be (big-endian arm64).
|
|
- This documentation describes the Rust support for Linux MIPS Release 6
targets.
- Also update the status of mipsisa64r6el-unknown-linux-gnuabi64i in
SUMMARY, as we have successfully built the native toolchain.
- Also fill out the description of MIPS R6 targets in SUMMARY.
|
|
|
|
|
|
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".
|
|
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".
|
