Bring back slice::ref_slice as slice::from_ref.
These functions were deprecated and removed in 1.5, but such simple
functionality shouldn't require using unsafe code, and it isn't
cluttering libstd too much.
The original removal was quite contentious (see #27774), since then
we've had precedent for including such nuggets of functionality (see rust-lang/rfcs#1789),
and @nikomatsakis has provided a lot of use cases in https://github.com/rust-lang/rfcs/pull/1789#issuecomment-314640034.
Hence this PR.
I'm not too sure what to do with stability, feel free to correct me.
It seems pointless to go through stabilization for these functions though.
cc @aturon
Implement TryFrom<&[T]> for &[T; N]
There are many cases where a buffer with a static compile-time size is preferred over a slice with a dynamic size. This allows for performing a checked conversion from `&[T]` to `&[T; N]`. This may also lead to compile-time optimizations involving `[T; N]` such as loop unrolling.
This is my first PR to Rust, so I'm not sure if discussion of this change should happen here or does it need its own RFC? I figured these changes would be a subset of #33417.
Implement Hash for raw pointers to unsized types
This is useful for some niche cases, like a hash table of slices or trait objects where the key is the raw pointer. Example use case: https://docs.rs/by_address
These functions were deprecated and removed in 1.5, but such simple
functionality shouldn't require using unsafe code, and it isn't
cluttering libstd too much.
incr.comp.: Use 128bit SipHash for fingerprinting
This PR switches incr. comp. result fingerprinting from 128 bit BLAKE2 to 128 bit SipHash. When we started using BLAKE2 for fingerprinting, the 128 bit version of SipHash was still experimental. Now that it isn't anymore we should be able to get a nice performance boost without significantly increasing collision probability.
~~I'm going to start a try-build for this, so we can gauge the performance impact before merging (hence the `WIP` in the title).~~
EDIT: Performance improvements look as expected. Tests seem to be passing.
Fixes#41215.
core: derive Clone for result::IntoIter
It appears to be a simple oversight that `result::IntoIter<T>` doesn't
implement `Clone` (where `T: Clone`). We do already have `Clone` for
`result::Iter`, as well as the similar `option::IntoIter` and `Iter`.
Optimize comparison functions of Iterator
Replaced matching on tuples which led to less performant code generation. Testing on microbenchmarks consistently showed ~1.35x improvement in performance on my machine.
Fixes#44729.
It appears to be a simple oversight that `result::IntoIter<T>` doesn't
implement `Clone` (where `T: Clone`). We do already have `Clone` for
`result::Iter`, as well as the similar `option::IntoIter` and `Iter`.
Ensure std::mem::Discriminant is Send + Sync
`PhantomData<*const T>` has the implication of Send / Syncness following
the *const T type, but the discriminant should always be Send and Sync.
Use `PhantomData<fn() -> T>` which has the same variance in T, but is Send + Sync
`PhantomData<*const T>` has the implication of Send / Syncness following
the *const T type, but the discriminant should always be Send and Sync.
Use `PhantomData<fn() -> T>` which has the same variance in T, but is Send + Sync
update FIXME(#6298) to point to open issue 15020
update FIXME(#6268) to point to RFC 811
update FIXME(#10520) to point to RFC 1751
remove FIXME for emscripten issue 4563 and include target in `test_estimate_scaling_factor`
remove FIXME(#18207) since node_id isn't used for `ref` pattern analysis
remove FIXME(#6308) since DST was implemented in #12938
remove FIXME(#2658) since it was decided to not reorganize module
remove FIXME(#20590) since it was decided to stay conservative with projection types
remove FIXME(#20297) since it was decided that solving the issue is unnecessary
remove FIXME(#27086) since closures do correspond to structs now
remove FIXME(#13846) and enable `function_sections` for windows
remove mention of #22079 in FIXME(#22079) since this is a general FIXME
remove FIXME(#5074) since the restriction on borrow were lifted
Docs for size_of::<#[repr(C)]> items.
Most of this info comes from camlorn's blog post on optimizing struct layout and the Rustonomicon.
I don't really like my wording in the first paragraph.
I also cannot find a definition of what `#[repr(C)]` does for enums that have variants with fields. They're allowed, unlike `#[repr(C)] enum`s with no variants.
remove FIXME(#13101) since `assert_receiver_is_total_eq` stays.
remove FIXME(#19649) now that stability markers render.
remove FIXME(#13642) now the benchmarks were moved.
remove FIXME(#6220) now that floating points can be formatted.
remove FIXME(#18248) and write tests for `Rc<str>` and `Rc<[u8]>`
remove reference to irelevent issues in FIXME(#1697, #2178...)
update FIXME(#5516) to point to getopts issue 7
update FIXME(#7771) to point to RFC 628
update FIXME(#19839) to point to issue 26925
Normalize spaces in lang attributes.
So, like, I grepped for all `lang` attributes for *reasons* and I noticed that they all share the same spacing of `#[lang = "item_name"]` except these five instances. So I decided to fix that. So enjoy this PR of exactly ten spaces.
Improve wording for StepBy
No other iterator makes the distinction between an iterator and an iterator adapter
in its summary line, so change it to be consistent with all other adapters.
