Copy all `AsciiExt` methods to the primitive types directly in order to deprecate it later
**EDIT:** [this PR is ready now](https://github.com/rust-lang/rust/pull/44042#issuecomment-333883548). I edited this post to reflect the current status of discussion, which is (apart from code review) pretty much settled.
---
This is my current progress in order to prepare stabilization of #39658. As discussed there (and in #39659), the idea is to deprecated `AsciiExt` and copy all methods to the type directly. Apparently there isn't really a reason to have those methods in an extension trait¹.
~~This is **work in progress**: copy&pasting code while slightly modifying the documentation isn't the most exciting thing to do. Therefore I wanted to already open this WIP PR after doing basically 1/4 of the job (copying methods to `&[u8]`, `char` and `&str` is still missing) to get some feedback before I continue. Some questions possibly worth discussing:~~
1. ~~Does everyone agree that deprecating `AsciiExt` is a good idea? Does everyone agree with the goal of this PR?~~ => apparently yes
2. ~~Are my changes OK so far? Did I do something wrong?~~
3. ~~The issue of the unstable-attribute is currently set to 0. I would wait until you say "Ok" to the whole thing, then create a tracking issue and then insert the correct issue id. Is that ok?~~
4. ~~I tweaked `eq_ignore_ascii_case()`: it now takes the argument `other: u8` instead of `other: &u8`. The latter was enforced by the trait. Since we're not bound to a trait anymore, we can drop the reference, ok?~~ => I reverted this, because the interface has to match the `AsciiExt` interface exactly.
¹ ~~Could it be that we can't write `impl [u8] {}`? This might be the reason for `AsciiExt`. If that is the case: is there a good reason we can't write such an impl block? What can we do instead?~~ => we couldn't at the time this PR was opened, but Simon made it possible.
/cc @SimonSapin @zackw
Fix#18604: next_power_of_two should panic on overflow
Fixes https://github.com/rust-lang/rust/issues/18604
Is it possible to write a test for this? My experiments showed `x.py test` running in release mode, so my attempt at a `#[should_panic]` didn't work.
We don't want to stabilize them now already. The goal of this set of
commits is just to add inherent methods to the four types. Stabilizing
all of those methods can be done later.
Since the methods on u8 directly will shadow the AsciiExt methods,
we cannot change the signature without breaking everything. It
would have been nice to take `u8` as argument instead of `&u8`, but
we cannot break stuff! So this commit reverts it to the original
`&u8` version.
Those methods will shadow the methods of `AsciiExt`, so if we don't
make them insta-stable, everyone will hitting stability errors. It
is fine adding those as stable, because they are just being moved
around [according to sfackler][1].
OPEN QUESTION: this commit also stabilizes the `AsciiExt` methods
that were previously feature gated by the `ascii_ctype` feature.
Maybe we don't want to stablilize those yet.
[1]: https://github.com/rust-lang/rust/pull/44042#issuecomment-329939279
This is the first step in order to deprecate AsciiExt. Since
this is a WIP commit, there is still some code duplication (notably
the static arrays) that will be removed later.
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
