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.
Document From trait implementations for OsStr, OsString, CString, and CStr
As part of issue #51430 (cc @skade).
The allocation and copy claims should be double-checked.
r? @steveklabnik
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" and "llvm", this enables HermitCore applications to be
written in Rust.
Don't format!() string literals
Prefer `to_string()` to `format!()` take 2, this time targetting string literals. In some cases (`&format!("...")` -> `"..."`) also removes allocations. Occurences of `format!("")` are changed to `String::new()`.
Replace push loops with extend() where possible
Or set the vector capacity where I couldn't do it.
According to my [simple benchmark](https://gist.github.com/ljedrz/568e97621b749849684c1da71c27dceb) `extend`ing a vector can be over **10 times** faster than `push`ing to it in a loop:
10 elements (6.1 times faster):
```
test bench_extension ... bench: 75 ns/iter (+/- 23)
test bench_push_loop ... bench: 458 ns/iter (+/- 142)
```
100 elements (11.12 times faster):
```
test bench_extension ... bench: 87 ns/iter (+/- 26)
test bench_push_loop ... bench: 968 ns/iter (+/- 3,528)
```
1000 elements (11.04 times faster):
```
test bench_extension ... bench: 311 ns/iter (+/- 9)
test bench_push_loop ... bench: 3,436 ns/iter (+/- 233)
```
Seems like a good idea to use `extend` as much as possible.
Impl Send & Sync for JoinHandle
This is just a cosmetic change - it slightly relaxes and clarifies the public API without effectively promising any new guarantees.
Currently we have [these auto trait implementations](https://doc.rust-lang.org/nightly/std/thread/struct.JoinHandle.html#synthetic-implementations):
```rust
impl<T: Send> Send for JoinHandle<T> {}
impl<T: Sync> Sync for JoinHandle<T> {}
```
Bound `T: Send` doesn't make much sense because `JoinHandle<T>` can be created only when `T: Send`. Note that [`JoinHandle::<T>::join`](https://doc.rust-lang.org/nightly/std/thread/struct.JoinHandle.html#method.join) doesn't require `T: Send` so why should the `Send` impl?
And the `Sync` impl doesn't need `T: Sync` because `JoinHandle<T>` cannot even share `T` - it can only send it to the thread that calls `join`.
