| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
|
|
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
|
|
|
|
|
|
This makes it possible to instruct libstd to never touch the signal
handler for `SIGPIPE`, which makes programs pipeable by default (e.g.
with `./your-program | head -n 1`) without `ErrorKind::BrokenPipe`
errors.
|
|
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.
|
|
|
|
|
|
Update books
## reference
2 commits in a92be0fef439b3d8e0468d82cb24812d303520a0..f3d3953bf3b158d596c96d55ce5366f9f3f972e9
2022-07-21 19:01:23 -0700 to 2022-08-01 17:17:37 -0700
- Add `let_chains` references (rust-lang/reference#1179)
- Remove outdated warning (rust-lang/reference#1243)
## rust-by-example
18 commits in 3155db49b0d57cd82c65456ac210b69ecec5ccb1..ee342dc91e1ba1bb1e1f1318f84bbe3bfac04798
2022-07-05 20:35:53 -0300 to 2022-07-27 11:06:36 -0300
- Closure inferred twice (rust-lang/rust-by-example#1588)
- fix a syntax bug in example assembly (rust-lang/rust-by-example#1511)
- Minor grammar change in src/std/rc.md paragraph 2 (rust-lang/rust-by-example#1586)
- Fix typo in asm.md (rust-lang/rust-by-example#1585)
- Fix incorrect padding in fixed-width print (rust-lang/rust-by-example#1584)
- Update print.md (rust-lang/rust-by-example#1582)
- add-chapter-on-defaults (rust-lang/rust-by-example#1580)
- Fix typo (rust-lang/rust-by-example#1579)
- fix a compile error (rust-lang/rust-by-example#1578)
- Suggest using mod.rs pattern to share test code (rust-lang/rust-by-example#1577)
- fix a compile error in iter_any.md (rust-lang/rust-by-example#1576)
- Mention attribute like macros in attributes.md (rust-lang/rust-by-example#1574)
- Update exercise to be clearer (rust-lang/rust-by-example#1573)
- fixes link for turbofish in testcase_mapreduce.md (rust-lang/rust-by-example#1572)
- Fix inconsistency between comment and code in hello/print.md (rust-lang/rust-by-example#1571)
- Fixes a typo in print.md (rust-lang/rust-by-example#1570)
- into_iter-moves-elements (rust-lang/rust-by-example#1569)
- Fix a typo in print.md (rust-lang/rust-by-example#1568)
## rustc-dev-guide
16 commits in d5201cddace979b299ec1bf9fd8997338151aa9d..04f3cf0bb2f5a6ee2bfc4b1a6a6cd8c11d1c5531
2022-07-21 04:48:49 +0200 to 2022-07-31 07:46:57 +0200
- address review comment
- accept review suggestion
- try address review comments
- summary of chapter
- Update src/building/compiler-documenting.md
- revamp doc-build chapter
- minor fixes
- Prefer relative links
- Fix the link to clippy docs
- Fix the link to `ResolverAstLowering`
- Fix the link to `ProcMacro` trait
- Fix the link to `Lazy<T>`
- Add instructions to fix build errors in std after adding a new target
- Document how to build a cross-compiler
- Add documentation about Microsoft provided debuggers and CodeView/PDB… (rust-lang/rustc-dev-guide#1406)
- rust-analyzer is now a subtree
## embedded-book
2 commits in 766979590da8100998f0d662499d4a901d8d1640..befe6840874311635c417cf731377f07234ee373
2022-07-04 09:13:58 +0000 to 2022-07-25 07:51:14 +0000
- Updated instructions for running first Hardware example (rust-embedded/book#323)
- Improved ligability for hardware.md (rust-embedded/book#324)
|
|
|
|
This brings the `--crate-type`, `--emit`, and `--print` options' allowed arguments into sync with that printed by `rustc --help`.
|
|
`-Z location-detail`: provide option to disable all location details
As reported [here](https://github.com/rust-lang/rust/pull/89920#issuecomment-1190598924), when I first implemented the `-Z location-detail` flag there was a bug, where passing an empty list was not correctly supported, and instead rejected by the compiler. This PR fixes that such that passing an empty list results in no location details being tracked, as originally specified in https://github.com/rust-lang/rfcs/pull/2091 .
This PR also adds a test case to verify that this option continues to work as intended.
|
|
Remove implicit names and values from `--cfg` in `--check-cfg`
This PR remove the implicit names and values from `--cfg` in `--check-cfg` because the behavior is quite surprising but also because it's really easy to inadvertently really on the implicitness and when the `--cfg` is not set anymore to have an unexpected warning from an unexpected condition that pass with the implicitness.
This change in behavior will also enable us to warn when an unexpected `--cfg` is passed, ex: the user wrote `--cfg=unstabl` instead of `--cfg=unstable`. The implementation of the warning will be done in a follow-up PR.
cc `@petrochenkov`
|
|
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
|
|
doc/rustc: describe the uefi target platforms
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/)
|
|
|
|
Prior to this fix, `-Z location-detail` provided no mechanism for
disabling all location details. This commit also adds a test case
to verify that this option continues to work as intended, and
clarifies the documentation of this option.
|
|
|
|
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>
|
|
|
|
Add fine-grained LLVM CFI support to the Rust compiler
This PR improves the LLVM Control Flow Integrity (CFI) support in the Rust compiler by providing forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types.
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue https://github.com/rust-lang/rust/issues/89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
Thank you again, `@eddyb,` `@nagisa,` `@pcc,` and `@tmiasko` for all the help!
|
|
Add support for LLVM ShadowCallStack.
LLVMs ShadowCallStack provides backward edge control flow integrity protection by using a separate shadow stack to store and retrieve a function's return address.
LLVM currently only supports this for AArch64 targets. The x18 register is used to hold the pointer to the shadow stack, and therefore this only works on ABIs which reserve x18. Further details are available in the [LLVM ShadowCallStack](https://clang.llvm.org/docs/ShadowCallStack.html) docs.
# Usage
`-Zsanitizer=shadow-call-stack`
# Comments/Caveats
* Currently only enabled for the aarch64-linux-android target
* Requires the platform to define a runtime to initialize the shadow stack, see the [LLVM docs](https://clang.llvm.org/docs/ShadowCallStack.html) for more detail.
|
|
This commit updates the documentation for the LLVM Control Flow
Integrity (CFI) support in the Rust compiler (see #95548 and #89653).
|
|
|
|
|
|
Adds support for the LLVM ShadowCallStack sanitizer.
|
|
|
|
I can't think of any other reason CI might be failing, and I should've
done this anyway.
|
|
|
|
|
|
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`).
Rename it to be more clear.
|
|
Build the Clippy book as part of x.py doc
r? ``@ehuss`` since you said you would be interested in helping moving this forward.
cc ``@jyn514`` as part of the bootstrap team.
|