| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add Platform Support documentation for MIPS Release 6 targets
This is a follow-up to our to-announce MCP, rust-lang/compiler-team#638, where we proposed to assign several maintainers for MIPS R6 targets and was told to explain that this set of targets are experimental in nature.
This documentation describes Rust support for `mipsisa*r6*-unknown-linux-gnu*` targets (mainly `mipsisa64r6el-unknown-linux-gnuabi64`), including toolchain setup, building, and testing procedures.
|
|
|
|
|
|
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+.
|
|
|
|
Tested with the Gaisler bcc2 toolchain (both gcc and clang) and the Leon3 simulator.
|
|
Update books
## rust-lang/book
1 commits in 21cf840842bdf768a798869f06373c96c1cc5122..668c64760b5c7ea654facb4ba5fe9faddfda27cc
2023-06-29 13:50:36 UTC to 2023-06-29 13:50:36 UTC
- Remove adjective about what kind of number this is
## rust-lang/edition-guide
2 commits in f63e578b92ff43e8cc38fcaa257b660f45c8a8c2..2751bdcef125468ea2ee006c11992cd1405aebe5
2023-07-10 14:29:51 UTC to 2023-07-08 18:05:44 UTC
- Update a link to a section in the cargo workspaces. (rust-lang/edition-guide#283)
- b'...' byte strings -> byte chars (rust-lang/edition-guide#282)
## rust-embedded/book
2 commits in f2aed2fe8e9f55508c86ba3aa4b6789b18a08a22..1e5556dd1b864109985d5871616ae6b9164bcead
2023-06-29 07:34:47 UTC to 2023-06-27 23:43:06 UTC
- add constgebra to list of math crates (rust-embedded/book#358)
- Switch to GHMQ (rust-embedded/book#357)
## rust-lang/nomicon
1 commits in c369e4b489332f8721fbae630354fa83385d457d..302b995bcb24b70fd883980fd174738c3a10b705
2023-07-05 16:08:32 UTC to 2023-07-05 16:08:32 UTC
- Minor improvements (rust-lang/nomicon#414)
## rust-lang/reference
5 commits in 5ca365eac678cb0d41a20b3204546d6ed70c7171..1ea0178266b3f3f613b0fabdaf16a83961c99cdb
2023-07-08 22:11:07 UTC to 2023-06-26 16:51:55 UTC
- Remove doc of unstable feature of never type (rust-lang/reference#1376)
- Typo: 'assingee' to 'assignee' in expressions.md (rust-lang/reference#1377)
- str type: make sentence more readable (rust-lang/reference#1374)
- Remove obsolete note about soundness hole in type-layout.md (rust-lang/reference#1367)
- Typo: 'a' to 'an' in destructors.md (rust-lang/reference#1371)
## rust-lang/rust-by-example
1 commits in 57636d6926762861f34e030d52ca25a71e95e5bf..8a87926a985ce32ca1fad1be4008ee161a0b91eb
2023-07-07 22:44:06 UTC to 2023-07-07 22:44:06 UTC
- Hint for RGB color calculation (rust-lang/rust-by-example#1726)
## rust-lang/rustc-dev-guide
18 commits in 17fe3e948498c50e208047a750f17d6a8d89669b..b5a12d95e32ae53791cc6ab44417774667ed2ac6
2023-07-09 14:50:50 UTC to 2023-06-28 04:55:24 UTC
- fix: update link to function coverage (rust-lang/rustc-dev-guide#1727)
- Fix a bug in getting-started.md (rust-lang/rustc-dev-guide#1726)
- improve explanation of placing tests in separate file (rust-lang/rustc-dev-guide#1721)
- various fixes/improvements to Contributing chapter (rust-lang/rustc-dev-guide#1723)
- ty::ConstKind has moved (rust-lang/rustc-dev-guide#1724)
- document `./x test --rustc-args` option (rust-lang/rustc-dev-guide#1719)
- tests/run-make files have moved (rust-lang/rustc-dev-guide#1716)
- replace dead link (rust-lang/rustc-dev-guide#1717)
- fix link (rust-lang/rustc-dev-guide#1718)
- update link (rust-lang/rustc-dev-guide#1709)
- typo (rust-lang/rustc-dev-guide#1706)
- OwningRef exists no more (rust-lang/rustc-dev-guide#1715)
- Try to avoid confusion (rust-lang/rustc-dev-guide#1713)
- Issue1707 doc simply use x (rust-lang/rustc-dev-guide#1710)
- include rustc-dev-guide's own issues in suggested search (rust-lang/rustc-dev-guide#1708)
- Improve feature gate and x.py docs (rust-lang/rustc-dev-guide#1701)
- Fix some links (rust-lang/rustc-dev-guide#1705)
- Define more lint terms. (rust-lang/rustc-dev-guide#1681)
|
|
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.
|
|
|
|
Signed-off-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`
|
|
|
|
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".
|
