| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Support `--print KIND=PATH` command line syntax
As is already done for `--emit KIND=PATH` and `-L KIND=PATH`.
In the discussion of #110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o` path to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`.
I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](https://github.com/facebook/buck2/blob/d43cf3a51a31f00be2c2248e78271b0fef0452b4/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system.
From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". https://github.com/rust-lang/cargo/blob/31eda6f7c360d9911f853b3014e057db61238f3e/src/cargo/core/compiler/build_context/target_info.rs#L242 (FYI `@weihanglo` as you dealt with this recently in https://github.com/rust-lang/cargo/pull/11633.)
Mentioning reviewers active in #110785: `@fee1-dead` `@jyn514` `@bjorn3`
|
|
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.
|
|
|
|
Add x86_64-unknown-linux-ohos target
This complements the existing `aarch64-unknown-linux-ohos` and `armv7-unknown-linux-ohos` targets.
This should be covered by the existing MCP (https://github.com/rust-lang/compiler-team/issues/568), but I can also create a new MCP if that is preferred.
|
|
Add a sparc-unknown-none-elf target.
# `sparc-unknown-none-elf`
**Tier: 3**
Rust for bare-metal 32-bit SPARC V7 and V8 systems, e.g. the Gaisler LEON3.
## Target maintainers
- Jonathan Pallant, `jonathan.pallant@ferrous-systems.com`, https://ferrous-systems.com
## Requirements
> Does the target support host tools, or only cross-compilation?
Only cross-compilation.
> Does the target support std, or alloc (either with a default allocator, or if the user supplies an allocator)?
Only tested with `libcore` but I see no reason why you couldn't also support `liballoc`.
> Document the expectations of binaries built for the target. Do they assume
specific minimum features beyond the baseline of the CPU/environment/etc? What
version of the OS or environment do they expect?
Tested by linking with a standard SPARC bare-metal toolchain - specifically I used the [BCC2] toolchain from Gaisler (both GCC and clang variants, both pre-compiled for x64 Linux and compiling my own SPARC GCC from source to run on `aarch64-apple-darwin`).
The target is set to use the lowest-common-denominator `SPARC V7` architecture (yes, they started at V7 - see [Wikipedia](https://en.wikipedia.org/wiki/SPARC#History)).
[BCC2]: https://www.gaisler.com/index.php/downloads/compilers
> Are there notable `#[target_feature(...)]` or `-C target-feature=` values that
programs may wish to use?
`-Ctarget-cpu=v8` adds the instructions added in V8.
`-Ctarget-cpu=leon3` adds the V8 instructions and sets up scheduling to suit the Gaisler LEON3.
> What calling convention does `extern "C"` use on the target?
I believe this is defined by the SPARC architecture reference manuals and V7, V8 and V9 are all compatible.
> What format do binaries use by default? ELF, PE, something else?
ELF
## Building the target
> If Rust doesn't build the target by default, how can users build it? Can users
just add it to the `target` list in `config.toml`?
Yes. I did:
```toml
target = ["aarch64-apple-darwin", "sparc-unknown-none-elf"]
```
## Building Rust programs
> Rust does not yet ship pre-compiled artifacts for this target. To compile for
this target, you will either need to build Rust with the target enabled (see
"Building the target" above), or build your own copy of `core` by using
`build-std` or similar.
Correct.
## Testing
> Does the target support running binaries, or do binaries have varying
expectations that prevent having a standard way to run them?
No - it's a bare metal platform.
> If users can run binaries, can they do so in some common emulator, or do they need native
hardware?
But if you use [BCC2] as the linker, you get default memory map suitable for the LEON3, and a default BSP for the LEON3, and so you can run the binaries in the `tsim-leon3` simulator from Gaisler.
```console
$ cat .cargo/config.toml | grep runner
runner = "tsim-leon3 -c sim-commands.txt"
$ cat sim-commands.txt
run
quit
$ cargo +sparcrust run --targe=sparc-unknown-none-elf
Compiling sparc-demo-rust v0.1.0 (/work/sparc-demo-rust)
Finished dev [unoptimized + debuginfo] target(s) in 3.44s
Running `tsim-leon3 -c sim-commands.txt target/sparc-unknown-none-elf/debug/sparc-demo-rust`
TSIM3 LEON3 SPARC simulator, version 3.1.9 (evaluation version)
Copyright (C) 2023, Frontgrade Gaisler - all rights reserved.
This software may only be used with a valid license.
For latest updates, go to https://www.gaisler.com/
Comments or bug-reports to support@gaisler.com
This TSIM evaluation version will expire 2023-11-28
Number of CPUs: 2
system frequency: 50.000 MHz
icache: 1 * 4 KiB, 16 bytes/line (4 KiB total)
dcache: 1 * 4 KiB, 16 bytes/line (4 KiB total)
Allocated 8192 KiB SRAM memory, in 1 bank at 0x40000000
Allocated 32 MiB SDRAM memory, in 1 bank at 0x60000000
Allocated 8192 KiB ROM memory at 0x00000000
section: .text, addr: 0x40000000, size: 104400 bytes
section: .rodata, addr: 0x400197d0, size: 15616 bytes
section: .data, addr: 0x4001d4d0, size: 1176 bytes
read 1006 symbols
Initializing and starting from 0x40000000
Hello, this is Rust!
PANIC: PanicInfo { payload: Any { .. }, message: Some(I am a panic), location: Location { file: "src/main.rs", line: 33, col: 5 }, can_unwind: true }
Program exited normally on CPU 0.
```
> Does the target support running the Rust testsuite?
I don't think so, the testsuite requires `libstd` IIRC.
## Cross-compilation toolchains and C code
> Does the target support C code?
Yes.
> If so, what toolchain target should users use to build compatible C code? (This may match the target triple, or it may be a toolchain for a different target triple, potentially with specific options or caveats.)
I suggest [BCC2] from Gaisler. It comes in both GCC and Clang variants.
|
|
fix typo in `rustdoc/src/what-is-rustdoc.md`
|
|
platform-support.md: It's now verified that NetBSD/riscv64 can self-h…
…ost.
|
|
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.
|
