set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
fix a typo: taget_env -> target_env
This typo was introduced in https://github.com/rust-lang/rust/pull/47334. A couple tests bitrotted as a result, so we fix those too, and move them to a more sensible place.
Is there some lint we could turn on that would've caught this? It's a drag that cfg typos can silently pass through the compiler.
In case that it is statically known that the OS doesn't support
`getrandom` (non-Linux) or becomes clear at runtime that `getrandom`
isn't available (`ENOSYS`), the opened fd ("/dev/urandom") isn't closed
after the function, so that future calls can reuse it. This saves
repeated `open`/`close` system calls at the cost of one permanently open
fd.
Additionally, this skips the initial zero-length `getrandom` call and
directly hands the user buffer to the operating system, saving one
`getrandom` syscall.
std: stop backtracing when the frames are full
This is a defensive measure to mitigate the infinite unwind loop seen in #53372. That case will still repeatedly unwind `__rust_try`, but now it will at least stop when `cx.frames` is full.
r? @alexcrichton
Use #[non_exhaustive] on internal enums
This replaces `__Nonexhaustive` variants (and variants thereof) with `#[non_exhaustive]`. These were mostly unstable previously, with the exception of the `cloudabi` enums and `Level` in proc_macro: these were `#[doc(hidden)]`, so clearly intended not to be used directly. It should be safe to replace all of these.
This commit adds the necessary definitions for target specs and such as well as
the necessary support in libstd to compile basic `aarch64-pc-windows-msvc`
binaries. The target is not currently built on CI, but it can be built locally
with:
./configure --target=aarch64-pc-windows-msvc --set rust.lld
./x.py build src/libstd --target aarch64-pc-windows-msvc
Currently this fails to build `libtest` due to a linker bug (seemingly in LLD?)
which hasn't been investigate yet. Otherwise though with libstd you can build a
hello world program (linked with LLD). I've not tried to execute it yet, but it
at least links!
Full support for this target is still a long road ahead, but this is hopefully a
good stepping stone to get started.
Points of note about this target are:
* Currently defaults to `panic=abort` as support is still landing in LLVM for
SEH on AArch64.
* Currently defaults to LLD as a linker as I was able to get farther with it
than I was with `link.exe`
Don't panic on std::env::vars() when env is null.
Fixes#53200.
Reviewer(s):
* Do I need to do any `#[cfg()]` here?
* Is this use of libc ok for a dev-dependency?
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!
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.
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.
Rollup of bare_trait_objects PRs
All deny attributes were moved into bootstrap so they can be disabled with a line of config.
Warnings for external tools are allowed and it's up to the tool's maintainer to keep it warnings free.
r? @Mark-Simulacrum
cc @ljedrz @kennytm
