There are a few places where we mention the replacement character in the
docs, and it could be helpful for users to utilize the constant which is
available in the standard library, so let’s link to it!
Rollup of 15 pull requests
Successful merges:
- #52773 (Avoid unnecessary pattern matching against Option and Result)
- #53082 (Fix doc link (again))
- #53094 (Automatically expand section if url id point to one of its component)
- #53106 (atomic ordering docs)
- #53110 (Account for --remap-path-prefix in save-analysis)
- #53116 (NetBSD: fix signedess of char)
- #53179 (Whitelist wasm32 simd128 target feature)
- #53183 (Suggest comma when missing in macro call)
- #53207 (Add individual docs for rotate_{left, right})
- #53211 ([nll] enable feature(nll) on various crates for bootstrap)
- #53214 ([nll] enable feature(nll) on various crates for bootstrap: part 2)
- #53215 (Slightly refactor syntax_ext/format)
- #53217 (inline some short functions)
- #53219 ([nll] enable feature(nll) on various crates for bootstrap: part 3)
- #53222 (A few cleanups for rustc_target)
clarify partially initialized Mutex issues
Using a `sys_common::mutex::Mutex` without calling `init` is dangerous, and yet there are some places that do this. I tried to find all of them and add an appropriate comment about reentrancy.
I found two places where (I think) reentrancy can actually occur, and was not able to come up with an argument for why this is okay. Someone who knows `io::lazy` and/or `sys_common::at_exit_imp` should have a careful look at this.
Remove references to `StaticMutex` which got removed a while ago
`StaticMutex` got removed two years ago with https://github.com/rust-lang/rust/pull/34705, but still got referenced in some comments and even an error explanation.
Specify reentrancy gurantees of `Once::call_once`
I don't think the docs are clear about what happens in the following code
```rust
static INIT: Once = ONCE_INIT;
INIT.call_once(|| INIT.call_once(|| println!("huh?")));
```
[Playground](https://play.rust-lang.org/?gist=15dde1f68a6ede263c7250c36977eade&version=stable&mode=debug&edition=2015)
Let's "specify" the behavior to make it clear that the current behavior (deadlock I think?) is not a strict guarantee.
Add targets for HermitCore (https://hermitcore.org) to the Rust compiler and port libstd to it.
As a start, the port uses the simplest possible configuration (no jemalloc, abort on panic) and makes use of existing Unix-specific code wherever possible.
It adds targets for x86_64 (current main HermitCore platform) and aarch64 (HermitCore platform under development).
Together with the patches to "liblibc" (https://github.com/rust-lang/libc/pull/1048) and llvm (https://github.com/rust-lang/llvm/pull/122), this enables HermitCore applications to be written in Rust.
