impl Hasher for {&mut Hasher, Box<Hasher>}
**Rationale:** The `Hash` trait has `fn hash<H: Hasher>(&self, state: &mut H)`, which can only accept a `Sized` hasher, even if the `Hasher` trait is object-safe. We cannot retroactively add the `?Sized` bound without breaking stability, thus implementing `Hasher` to a trait object reference is the next best solution.
**Warning:** These `impl` are insta-stable, and should need an FCP. I don't think a full RFC is necessary.
Add or_default to Entry APIs
As argued for in #44324, this PR adds a new `or_default` method to the various `Entry` APIs (currently just for `BTreeMap` and `HashMap`) when `V: Default`. This method is effectively a shorthand for `or_insert_with(Default::default)`.
std: Mark allocation functions as nounwind
This commit flags all allocation-related functions in liballoc as "this can't
unwind" which should largely resolve the size-related issues found on #42808.
The documentation on the trait was updated with such a restriction (they can't
panic) as well as some other words about the relative instability about
implementing a bullet-proof allocator.
Closes#42808
Generator support
This adds experimental support for generators intended to land once https://github.com/rust-lang/rfcs/pull/2033 is approved.
This is not yet ready to be merged. Things to do:
- [x] Make closure arguments on generators an error
- [x] Spot FIXMEs
- [x] Pass make tidy
- [x] Write tests
- [x] Document the current syntax and semantics for generators somewhere
- [x] Use proper error message numbers
- [x] ~~Make the implicit argument type default to `()`~~
This commit flags all allocation-related functions in liballoc as "this can't
unwind" which should largely resolve the size-related issues found on #42808.
The documentation on the trait was updated with such a restriction (they can't
panic) as well as some other words about the relative instability about
implementing a bullet-proof allocator.
Closes#42808
Clarify that VecDeque::swap can panic
The previous documentation mentioned this, but ambiguously used the term "fail".
This clarifies that the function will panic if the index is out of bounds, instead of silently failing and not doing anything.
If there's anything else I can do to improve this PR, I'd be happy to do so! Just saw this when reading through the docs in passing - it was slightly unclear what "fail" meant.
The previous documentation mentioned this, but ambiguously used the term "fail".
This clarifies that the function will panic if the index is out of bounds, instead of silently failing and not doing anything.
Fix inconsistent doc headings
This fixes headings reading "Unsafety" and "Example", they should be "Safety" and "Examples" according to RFC 1574.
r? @steveklabnik
Implement From<&[T]> and others for Arc/Rc (RFC 1845)
* Implements `From<`{`&[T]`, `&str`, `String`, `Box<T> where T: ?Sized`, `Vec<T>`}`>` for `Arc`/`Rc`
* Removes `rustc_private`-marked methods `Rc::__from_array` and `Rc::__from_str`, replacing their use with `Rc::from`
Tracking issue: #40475
Implements RFC 1845, adding implementations of:
* `From<&[T]>` for `Rc<[T]>`
* `From<&str>` for `Rc<str>`
* `From<String>` for `Rc<str>`
* `From<Box<T: ?Sized>>` for `Rc<T>`
* `From<Vec<T>>` for `Rc<[T]>`
* and likewise for `Arc<_>`
Also removes now-obsolete internal methods `Rc::__from_array` and
`Rc::__from_str`, replacing their use with `Rc::from`.
Add Vec::drain_filter
This implements the API proposed in #43244.
So I spent like half a day figuring out how to implement this in some awesome super-optimized unsafe way, which had me very confident this was worth putting into the stdlib.
Then I looked at the impl for `retain`, and was like "oh dang". I compared the two and they basically ended up being the same speed. And the `retain` impl probably translates to DoubleEndedIter a lot more cleanly if we ever want that.
So now I'm not totally confident this needs to go in the stdlib, but I've got two implementations and an amazingly robust test suite, so I figured I might as well toss it over the fence for discussion.
