implement unsafe pointer methods
I also cleaned up some existing documentation a bit here or there since I was doing so much auditing of it. Most notably I significantly rewrote the `offset` docs to clarify safety (`*const` and `*mut`'s offset docs had actually diverged).
Individualize feature gates for const fn invocation
This PR changes the meaning of `#![feature(const_fn)]` so it is only required to declare a const fn but not to call one. Based on discussion at #24111. I was hoping we could have an FCP here in order to move that conversation forward.
This sets the stage for future stabilization of the constness of several functions in the standard library (listed below), so could someone please tag the lang team for review.
- `std::cell`
- `Cell::new`
- `RefCell::new`
- `UnsafeCell::new`
- `std::mem`
- `size_of`
- `align_of`
- `std::ptr`
- `null`
- `null_mut`
- `std::sync`
- `atomic`
- `Atomic{Bool,Ptr,Isize,Usize}::new`
- `once`
- `Once::new`
- primitives
- `{integer}::min_value`
- `{integer}::max_value`
Some other functions are const but they are also unstable or hidden, e.g. `Unique::new` so they don't have to be considered at this time.
After this stabilization, the following `*_INIT` constants in the standard library can be deprecated. I wasn't sure whether to include those deprecations in the current PR.
- `std::sync`
- `atomic`
- `ATOMIC_{BOOL,ISIZE,USIZE}_INIT`
- `once`
- `ONCE_INIT`
Fix example in transmute; add safety requirement to Vec::from_raw_parts
This fixes the second bullet point on #44281 and also removes some incorrect information.
`FlatMap` can use internal iteration for its `fold`, which shows a
performance advantage in the new benchmarks:
test iter::bench_flat_map_chain_ref_sum ... bench: 4,354,111 ns/iter (+/- 108,871)
test iter::bench_flat_map_chain_sum ... bench: 468,167 ns/iter (+/- 2,274)
test iter::bench_flat_map_ref_sum ... bench: 449,616 ns/iter (+/- 6,257)
test iter::bench_flat_map_sum ... bench: 348,010 ns/iter (+/- 1,227)
... where the "ref" benches are using `by_ref()` that isn't optimized.
So this change shows a decent advantage on its own, but much more when
combined with a `chain` iterator that also optimizes `fold`.
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.
Additional traits for std::mem::ManuallyDrop
The first commit adds `Clone` and `Copy` trait implementations for `ManuallyDrop`. Although `Drop` and `Copy` cannot be used together, this may be useful for generics.
The second commit adds implementations common traits. I do not think this is necessary, as they could be implemented in a wrapper type outside the standard library, but it would make `ManuallyDrop` more convenient to use.
update unimplemented! docs
For #42628 (updating docs from changes from #42155).
Initial changes made to make `unimplemented!` doc comments look more like `unreachable!` and remove statement about the panic message.
r? @steveklabnik
Although types that don't implement Drop can't be Copyable, this can
still be useful when ManuallyDrop is used inside a generic type. This
doesn't derive from Copy as that would require T: Copy + Clone, instead
it provides an impl of Clone for T: Clone.
