Fix the recent spurious breakage on AppVeyor.
Fixed the spurious error introduced by d2b5b7603b due to a wrongly resolved relative path on AppVeyor.
This only starts to happen today because we just entered the last week of the 6-week cycle.
In the `#building` section, the doc read that a default configuration "shall use around 3.5 GB of disk space." Changed "shall use" to "requires," as I don't think it's meant to sound so prescriptive.
Removed various update-reference and update-all-references scripts
A PR that addresses #50853 changes that made `update-reference` and `update-all-references` scripts obsolete.
Improve core::task::TaskObj
- Rename `UnsafePoll` to `UnsafeTask` to avoid confusion with `Poll`
- Rename `TaskObj::from_poll_task()` to `TaskObj::new()`
- Rename `TaskObj`'s `poll` and `drop` fields to `poll_fn` and `drop_fn`
- Implement `Future` for `TaskObj`. Reason: It's a custom trait object for a future, so it should implement future
- Remove `unsafe impl Sync` for `TaskObj`. I don't think we need it. Was this safe? `UnsafeTask` only requires to implement `Send`
@cramertj
@aturon
Don't auto-hide inherent impls even if `rustdoc-collapse == true`.
This PR changes the auto-collapse behavior when a page is first loaded:
* Inherent impls will never be collapsed by default (new behavior).
* Trait impls will always be collapsed by default, same as before.
* Other items are collapsed according to localStorage, same as before.
This should be much more useful since there is no hint what the content of a collapsed inherent impl would be (try to collapse everything in https://doc.rust-lang.org/std/vec/struct.Vec.html and guess where a method like `try_reserve` or `splice` would be).
Manually clicking the global [-]/[+] will still collapse/expand everything.
Replace `core::iter::AlwaysOk<T>` by `Result<T, !>`
#43278 has been fixed, so we don't need this struct anymore.
(Actually we don't even need `.unwrap()` thanks to `#![feature(exhaustive_patterns)]`)
Certain directories in `/proc` can cause the `ReadDir`
iterator to loop indefinitely. We get an error code (22) when
calling libc's `readdir_r` on these directories, but `entry_ptr`
is `NULL` at the same time, signalling the end of the directory
stream.
This change introduces an internal state to the iterator such
that the `Some(Err(..))` value will only be returned once when
calling `next`. Subsequent calls will return `None`.
fixes#50619