| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
Updates the descriptions of the various ARM targets in platform-support.md so they are a little more consistent.
For example, all instances of ARMv7 changed to ARMv7-A (as opposed to ARMv7-R and ARMv7-M).
|
|
|
|
|
|
|
|
|
|
|
|
GuillaumeGomez:rustdoc-search-whitespace-as-separator, r=notriddle
rustdoc: Allow whitespace as path separator like double colon
Fixes https://github.com/rust-lang/rust/issues/108447.
I think it makes sense since it allows more common cases, however it also makes the syntax heavier. Not sure what the rest of the team thinks about it. In any case we'll need to go through FCP.
Full explanation for the changes is available [here](https://github.com/rust-lang/rust/pull/108537#issuecomment-1589480564).
r? `@notriddle`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
