This allows analyzing the output programatically; for example, finding
the item with the highest `total_estimate`.
I also took the liberty of adding `untracked` tests to `rustc_session` and documentation to the unstable book for `dump-mono-items`.
Add LLVM KCFI support to the Rust compiler
This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)
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 #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
This commit adds initial documentation for LLVM Kernel Control Flow
Integrity (KCFI) support to the Rust compiler (see #105109 and #89653).
Co-authored-by: Miguel Ojeda <ojeda@users.noreply.github.com>
Document more settings for building rustc for Fuchsia
This documents that you need to link for Fuchsia with `lld` and provides configuration settings for both `clang` and `lld`. It also adjusts the documentation for running the test suite to recommend installing to a prefix.
r? ``@tmandry``
Issue error when -C link-self-contained option is used on unsupported platforms
The documentation was also updated to reflect this.
I'm assuming the supported platforms are the same as initially written in [RELEASES.md](https://github.com/rust-lang/rust/blob/master/RELEASES.md#compiler-17).
Fixes#103576
Update books
## nomicon
1 commits in 9c73283775466d22208a0b28afcab44db4c0cc10..05532356e7a4dbea2330aabb77611f5179493bb8
2022-09-30 07:31:22 +0900 to 2022-11-05 08:13:14 +0900
- Fix typos and grammatical errors (rust-lang/nomicon#384)
## reference
1 commits in 4ea7c5def38ac81df33a9e48e5637a82a5ac404d..9f0cc13ffcd27c1fbe1ab766a9491e15ddcf4d19
2022-10-25 15:14:36 -0700 to 2022-10-31 04:09:16 -0700
- Add a comma (rust-lang/reference#1289)
## book
12 commits in aa5ee485bd6bd80d205da7c82fcdd776f92fdd51..3f64052c048c6def93b94a2b514ee88bba918744
2022-10-20 16:49:55 -0400 to 2022-11-03 22:13:58 -0400
- Upgrade to Rust 1.65
- Upgrade to Rust 1.64
- Upgrade to Rust 1.63
- New ideas for the issue template to try
- Clarify that the conditional expression is the one under discussion
- Updates from copyedit of ch6
- Made Option<T> error explanation more clear
- Update ch06-01-defining-an-enum
- Upgrade mdbook
- Clarify that user1 can't be used as a whole instance. Fixesrust-lang/book#2978.
- Fix plural and incorrect phrase. Fixesrust-lang/book#3359.
- Updates from copyedit of ch5
## rust-by-example
4 commits in 03491f33375c5a2a1661c7fa4be671fe95ce1249..2b15c0abf2bada6e00553814336bc3e2d8399097
2022-10-21 07:30:08 -0300 to 2022-10-31 08:30:13 -0300
- Remove --edition from src/crates/using_lib.md (rust-lang/rust-by-example#1635)
- upgrade upload-artifact
- Clarify Fn in fn/closures/input_parameters.md (rust-lang/rust-by-example#1634)
- fix: erroneous white spaces in types/cast.md
## rustc-dev-guide
12 commits in 51a37ad19a15709d0601afbac6581f5aea6a45da..d0dc6c97a6486f68bac782fff135086eae6d77ec
2022-10-25 10:18:58 -0700 to 2022-11-07 16:49:22 +0200
- trans -> codegen
- Remove implementation details
- Update some more things and improve wording
- Update query.md
- replace tabs with spaces (rust-lang/rustc-dev-guide#1504)
- align code blocks with their paragraphs
- Fixes some typos (rust-lang/rustc-dev-guide#1502)
- UPDATE - mention of Diagnostic derive on enums
- trans -> codegen (rust-lang/rustc-dev-guide#1500)
- add note for err annotation formatting
- Remove `--bless` from pre-push hook suggestion
- Update for highfive transition.
Update note about unstable split-debuginfo flag.
split-debuginfo was effectively stabilized in #98051. The note about it requiring `-Z unstable-options` is no longer accurate.
The rules for when it is gated and when it is supported are somewhat complex. I considered removing the note entirely, or making it more generic, but opted to instead try to summarize the current state.
Add a tier 3 target for the Sony PlayStation 1
This adds a tier 3 target, `mipsel-sony-psx`, for the Sony PlayStation 1. I've tested it pretty thoroughly with [this SDK](https://github.com/ayrtonm/psx-sdk-rs) I wrote for it.
From the [tier 3 target policy](https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-3-target-policy) (I've omitted the subpoints for brevity, but read over everything)
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I'd be the designated developer
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
The target name follows the conventions of the existing PSP target (`mipsel-sony-psp`) and uses `psx` following the convention of the broader [PlayStation homebrew community](https://psx-spx.consoledev.net/).
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
No legal issues with this target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
👍
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
The psx supports `core` and `alloc`, but will likely not support `std` anytime soon.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
This target has an SDK and a `cargo-psx` tool for formatting binaries as psx executables. Documentation and examples are provided in the [psx-sdk-rs README](https://github.com/ayrtonm/psx-sdk-rs#psx-sdk-rs), the SDK and cargo tool are both available through crates.io and docs.rs has [SDK documentation](https://docs.rs/psx/latest/psx/).
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
👍
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
No problem
Enable varargs support for calling conventions other than C or cdecl
This patch makes it possible to use varargs for calling conventions,
which are either based on C (efiapi) or C is based on them (sysv64 and win64).
Also pinging ``@phlopsi,`` because he noticed first this oversight when writing a library for UEFI.
rustdoc: add missing URL redirect
https://github.com/rust-lang/rust/pull/94753 missed some redirect settings, and one of the missing URL shows up in an error message. This PR adds those redirects.
