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)`.
Implement downcast the like it exists for Box.
The implementation avoids using into_raw/from_raw, because the pointer
arithmetic which should cancel does not seem to optimize out at the
moment.
Since Rc<T> is never Send, only Rc<Any> and not Rc<Any + Send>
implements downcast.
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
