Stabilize spin_loop_hint
Stabilize `spin_loop_hint` in release `1.23.0`.
I've also renamed feature `hint_core_should_pause` to `spin_loop_hint`.
cc #41196
rustdoc: include external files in documentation (RFC 1990)
Part of https://github.com/rust-lang/rfcs/pull/1990 (needs work on the error reporting, which i'm deferring to after this initial PR)
cc #44732
Also fixes#42760, because the prep work for the error reporting made it easy to fix that at the same time.
show in docs whether the return type of a function impls Iterator/Read/Write
Closes#25928
This PR makes it so that when rustdoc documents a function, it checks the return type to see whether it implements a handful of specific traits. If so, it will print the impl and any associated types. Rather than doing this via a whitelist within rustdoc, i chose to do this by a new `#[doc]` attribute parameter, so things like `Future` could tap into this if desired.
### Known shortcomings
~~The printing of impls currently uses the `where` class over the whole thing to shrink the font size relative to the function definition itself. Naturally, when the impl has a where clause of its own, it gets shrunken even further:~~ (This is no longer a problem because the design changed and rendered this concern moot.)
The lookup currently just looks at the top-level type, not looking inside things like Result or Option, which renders the spotlights on Read/Write a little less useful:
<details><summary>`File::{open, create}` don't have spotlight info (pic of old design)</summary>
</details>
All three of the initially spotlighted traits are generically implemented on `&mut` references. Rustdoc currently treats a `&mut T` reference-to-a-generic as an impl on the reference primitive itself. `&mut Self` counts as a generic in the eyes of rustdoc. All this combines to create this lovely scene on `Iterator::by_ref`:
<details><summary>`Iterator::by_ref` spotlights Iterator, Read, and Write (pic of old design)</summary>
</details>
rustdoc book: talk about #![doc(test(no_crate_inject))] and #![doc(test(attr(...)))]
While investigating https://github.com/rust-lang/rust/issues/45750 i noticed that `#![doc(test(attr(...)))]` wasn't documented at all. Since this is useful for making your examples follow the same coding guidelines as your code, i wanted to add it to the Rustdoc Book. I also added `#![doc(test(no_crate_inject))]` since it's used in the same place and might be useful for macro-heavy crates. I added mentions for these to "The `doc` attribute" as well as "Documentation tests" since it's useful information in both places.
Technically the step reordering in the second commit is gated on https://github.com/rust-lang/rust/pull/45764, since before that lands attributes from the doctest come before the ones from `#![doc(test(attr(...)))]`.
This commit removes the `rand` crate from the standard library facade as
well as the `__rand` module in the standard library. Neither of these
were used in any meaningful way in the standard library itself. The only
need for randomness in libstd is to initialize the thread-local keys of
a `HashMap`, and that unconditionally used `OsRng` defined in the
standard library anyway.
The cruft of the `rand` crate and the extra `rand` support in the
standard library makes libstd slightly more difficult to port to new
platforms, namely WebAssembly which doesn't have any randomness at all
(without interfacing with JS). The purpose of this commit is to clarify
and streamline randomness in libstd, focusing on how it's only required
in one location, hashmap seeds.
Note that the `rand` crate out of tree has almost always been a drop-in
replacement for the `rand` crate in-tree, so any usage (accidental or
purposeful) of the crate in-tree should switch to the `rand` crate on
crates.io. This then also has the further benefit of avoiding
duplication (mostly) between the two crates!
RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute
This work-in-progress pull request contains my changes to implement [RFC 2008](https://github.com/rust-lang/rfcs/pull/2008). The related tracking issue is #44109.
As of writing, enum-related functionality is not included and there are some issues related to tuple/unit structs. Enum related tests are currently ignored.
WIP PR requested by @nikomatsakis [in Gitter](https://gitter.im/rust-impl-period/WG-compiler-middle?at=59e90e6297cedeb0482ade3e).
Bump to 1.23 and update bootstrap
This commit updates the bootstrap compiler, bumps the version to 1.23, updates
Cargo, updates books, and updates crates.io dependencies
Remove deprecated `collections` crate.
The real `collections` was merged with `alloc`, this facade was introduced [in this PR](https://github.com/rust-lang/rust/pull/42720) to give `#[no_std]` users time to adapt. This was done at least two cycles ago, now we can consider removing it for good.
Fix out of date unstable book entries for `alloc_*` features.
The `alloc_jemalloc` crate does not provide a type to use with `#[global_allocator]`, and (according to Alex) `extern crate alloc_jemalloc;` alone became a no-op when `#[global_allocator]` was introduced.
List of all lang items in unstable book.
I don't know how to link to the source code correctly, so I just put the information aside the lang item name.
Moved details of unstable non-ascii identifiers from the Reference
Moved details of unstable non-ascii identifiers from the Reference to the Unstable book
r? @steveklabnik
Implement `and_modify` on `Entry`
## Motivation
`Entry`s are useful for allowing access to existing values in a map while also allowing default values to be inserted for absent keys. The existing API is similar to that of `Option`, where `or` and `or_with` can be used if the option variant is `None`.
The `Entry` API is, however, missing an equivalent of `Option`'s `and_then` method. If it were present it would be possible to modify an existing entry before calling `or_insert` without resorting to matching on the entry variant.
Tracking issue: https://github.com/rust-lang/rust/issues/44733.
