| Age | Commit message (Collapse) | Author | Lines |
|
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
Add tier-3 support for powerpc64 and riscv64 openbsd
# powerpc64
- MCP for [powerpc64-unknown-openbsd tier-3 support](https://github.com/rust-lang/compiler-team/issues/551)
- only need to add spec definition in rustc_target
# riscv64
- MCP for [riscv64-unknown-openbsd tier-3 support](https://github.com/rust-lang/compiler-team/issues/552)
- add spec definition in rustc_target
- follow freebsd about avoiding linking with `libatomic`
|
|
Adding new Fuchsia rustup docs... reworking walkthrough
Docs improvements:
* Adding new `rustup` target add for Fuchsia targets
* Reworking walkthrough to show directory building as it happens
* Reworking walkthrough to use `hello_fuchsia_pkg/` directory
cc. `@djkoloski`
|
|
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
|
|
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
|
|
|
|
OpenBSD)
- add platform-support documentation
- add riscv64gc-unknown-openbsd spec
- do not try to link with -latomic on openbsd
|
|
|
|
Add the armv4t-none-eabi target to the supported_targets
This target was added in #100244 but forgot to add it to the macro in the `mod.rs` file.
``@Lokathor``
|
|
Improving Fuchsia rustc support documentation
* Adjusting `package/meta/package` to fit current schema
* Adding repository server step
* Adjusting step to give default repository
* Adding "recreate" step for easier step following
|
|
|
|
Improving wording
|
|
Add support for generating unique profraw files by default when using `-C instrument-coverage`
Currently, enabling the rustc flag `-C instrument-coverage` instruments the given crate and by default uses the naming scheme `default.profraw` for any instrumented profile files generated during the execution of a binary linked against this crate. This leads to multiple binaries being executed overwriting one another and causing only the last executable run to contain actual coverage results.
This can be overridden by manually setting the environment variable `LLVM_PROFILE_FILE` to use a unique naming scheme.
This PR adds a change to add support for a reasonable default for rustc to use when enabling coverage instrumentation similar to how the Rust compiler treats generating these same `profraw` files when PGO is enabled.
The new naming scheme is set to `default_%m_%p.profraw` to ensure the uniqueness of each file being generated using [LLVMs special pattern strings](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program).
Today the compiler sets the default for PGO `profraw` files to `default_%m.profraw` to ensure a unique file for each run. The same can be done for the instrumented profile files generated via the `-C instrument-coverage` flag as well which LLVM has API support for.
Linked Issue: https://github.com/rust-lang/rust/issues/100381
r? `@wesleywiser`
|
|
Use llvm-libunwind="in-tree" for Fuchsia targets
With updates to Fuchsia CI's Zircon libraries #99833, we can introduce `llvm-libunwind="in-tree"` for Fuchsia targets. This PR restores functionality removed from https://github.com/rust-lang/rust/pull/93604#issuecomment-1136515651.
cc `@tmandry` `@djkoloski`
|
|
|
|
|
|
linker-plugin-lto.md: Correct the name of example c file
The final output is linked with `cmain.o`, but we use `main.o` in the example.
This patch changes the name to `cmain.c` and `cmain.o` as the "C/C++ code as a dependency in Rust" section.
|
|
Removing libunwind from Fuchsia target docs
|
|
|
|
|
|
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
|
|
This is implementing the MCP from rust-lang/compiler-team#493. It is
increasing the minimum requirements of a couple Tier 1 targets, and
others at lower tiers, so this should go through FCP sign-offs for both
`T-compiler` and `T-release`.
The new `linux-gnu` baseline is kernel 3.2 and glibc 2.17. We will also
take that kernel as the minimum floor for _all_ `*-linux-*` targets, so
it may be broadly assumed in the implementation of the standard library.
That does not preclude specific targets from having greater requirements
where it makes sense, like a new arch needing something newer, or a
platform like `linux-android` choosing a newer baseline.
|
|
|
|
|
|
Add Fuchsia platform support documentation
This documentation contains instructions for building and running binaries on Fuchsia using its provided SDK.
|
|
Remove `$` prefix for bash scripts in doc
|
|
|
|
|
|
Add a `platform-support` entry to the rustc-docs for the different
`*-unknown-uefi` targets. This describes in detail how this platform
works, a few basic examples, and how to compile for the platform.
Red Hat is sponsoring my work on this platform, so I am putting myself
down as target maintainer. Co-maintainers are more than welcome to join
me in the effort. Communication is going on off-list to coordinate the
different efforts.
Note that the ultimate goal is to move the UEFI targets to Tier-2 so
bootloaders can be more easily supported in commercial products. This
documentation is the first step towards that goal, but should be a
viable documentation even for the current Tier-3 status of the targets.
I also want to point out that there is an ongoing GSoC-effort to port
the rust standard library to UEFI (by Ayush Singh). While this work is
not necessarily required to get to Tier-2, we definitely should
coordinate the efforts and update the documentation as soon as any such
ports are merged.
Note that the targets are already used by multiple commercial and non
commercial production systems, including, but not limited to:
* Tianocore-EDK2 (Official UEFI SDK by Intel) comes with rust support
in its staging repository (not part of any release, yet).
(https://github.com/tianocore/edk2-staging/tree)
* Intel's research program "Project Mu" uses the rust UEFI targets to
show possible future replacements for Tianocore-EDK2.
* The Rust OS "Redox" uses the UEFI targets for its bootloader.
(https://www.redox-os.org/)
* The hugely popular in-depth documentation of OS development in Rust
by Philipp Oppermann uses the UEFI targets.
(https://os.phil-opp.com/)
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
|
|
|
|
I can't think of any other reason CI might be failing, and I should've
done this anyway.
|
|
|
|
|
|
Co-authored-by: Mark Drobnak <mark.drobnak@gmail.com>
|
|
|
|
|
|
Signed-off-by: Sean Cross <sean@xobs.io>
|
|
Minor tweaks to rustc book summary formatting.
This includes a few minor tweaks to the summary/titles of chapters for the rustc book:
* Use a consistent chapter capitalization and hyphenation.
* Move "Codegen Options" underneath "Command-line Arguments". I feel like they are two closely related chapters, where codegen is just a subset of the total arguments.
* Move "Target Tier Policy" underneath "Platform Support". That chapter includes that policy for platform support, and thus I feel it is more closely related to that grouping.
|
|
|
|
This PR is fixes typo "avaiable" to "available".
|
|
|
|
|
|
|
|
Note the contacts for the nvptx64 target(s)
cc `@RDambrosio016` `@kjetilkjeka`
|
|
r=estebank,Mark-Simulacrum
Add missing rustc arg docs
Add documentation for recently added rustc args
`-C symbol-mangling-version` was stabilized in #90128.
`--json=future-incompat` was stabilized in #91535.
|
|
|
|
https://github.com/rust-lang/rust/pull/95604 implemented a better and more fine-grained way of keeping exported symbols alive.
|
|
Add missing links in platform support docs
I was looking at m68k support and saw that https://doc.rust-lang.org/rustc/platform-support.html and the sidebar there were missing some links to target documentation
|
|
|
|
|