Prefer String::from over from_str; String::from_str is unstable while
String::from is stable. Promote the latter by using it in examples.
Simply migrating unstable function to the closest alternative.
Some modest running-time improvements to `std::collections::BitSet` on bit-sets of varying set-membership densities. This is work originally from [here](https://github.com/rayglover/alt_collections). (Benchmarks copied below)
```
std::collections::BitSet / alt_collections::BitSet
copy_dense ... 3.08x
copy_sparse ... 4.22x
count_dense ... 11.01x
count_sparse ... 8.11x
from_bytes ... 1.47x
intersect_dense ... 6.54x
intersect_sparse ... 4.37x
union_dense ... 5.53x
union_sparse ... 5.60x
```
The exception is `from_bytes`, which I've left unaltered since the optimization is rather obscure.
Compiling with the cpu feature `popcnt` gave a further ~10% improvement on my machine, but this wasn't factored in to the benchmarks above.
Similar improvements could be made to `BitVec`, although that would probably require more substantial changes.
criticism welcome!
Using regular pointer arithmetic to iterate collections of zero-sized types
doesn't work, because we'd get the same pointer all the time. Our
current solution is to convert the pointer to an integer, add an offset
and then convert back, but this inhibits certain optimizations.
What we should do instead is to convert the pointer to one that points
to an i8\*, and then use a LLVM GEP instructions without the inbounds
flag to perform the pointer arithmetic. This allows to generate pointers
that point outside allocated objects without causing UB (as long as you
don't dereference them), and it wraps around using two's complement,
i.e. it behaves exactly like the wrapping_* operations we're currently
using, with the added benefit of LLVM being able to better optimize the
resulting IR.
Using regular pointer arithmetic to iterate collections of zero-sized types
doesn't work, because we'd get the same pointer all the time. Our
current solution is to convert the pointer to an integer, add an offset
and then convert back, but this inhibits certain optimizations.
What we should do instead is to convert the pointer to one that points
to an i8*, and then use a LLVM GEP instructions without the inbounds
flag to perform the pointer arithmetic. This allows to generate pointers
that point outside allocated objects without causing UB (as long as you
don't dereference them), and it wraps around using two's complement,
i.e. it behaves exactly like the wrapping_* operations we're currently
using, with the added benefit of LLVM being able to better optimize the
resulting IR.
The functions BitSet::{iter,union,symmetric_difference} each had docs that claimed u32s were output when their actual output each end up being usizes.
r? @steveklabnik
We don't need to copy any elements if `at` is behind the last element
in the map. The last element is at index `self.v.len() - 1`, so we
should not copy if `at` is greater **or equals** `self.v.len()`.
r? @Gankro
Several Minor API / Reference Documentation Fixes
- Fix a few small errors in the reference.
- Fix paper cuts in the API docs.
Fixes#24882Fixes#25233Fixes#25250
We don't need to copy any elements if `at` is behind the last element
in the map. The last element is at index `self.v.len() - 1`, so we
should not copy if `at` is greater or equals `self.v.len()`.
I was profiling my code again and this time AsRef<str> for String
was eating up a considerable chunk of my runtime; adding the inline
annotation made the program run almost twice as fast!
While I was at it I also added the annotation to other implementations
of AsRef as well as AsMut.
Ideally this trait implementation would be unstable, requiring crates to opt-in
if they would like the functionality, but that's not currently how stability
works so the implementation needs to be removed entirely.
This may come back at a future date, but for now the conservative option is to
remove it.
[breaking-change]
Ideally this trait implementation would be unstable, requiring crates to opt-in
if they would like the functionality, but that's not currently how stability
works so the implementation needs to be removed entirely.
This may come back at a future date, but for now the conservative option is to
remove it.
[breaking-change]
collections: Convert SliceConcatExt to use associated types
Coherence now allows this, we have `SliceConcatExt<T> for [V] where T: Sized + Clone` and` SliceConcatExt<str> for [S]`, these don't conflict because
str is never Sized.
According to rust-lang/rfcs#235, `VecDeque` should have this method (`VecDeque` was called `RingBuf` at the time) but it was never implemented.
I marked this stable since "1.0.0" because it's stable in `Vec`.
Coherence now allows this, we have SliceConcatExt<T> for [V] where T: Sized
+ Clone and SliceConcatExt<str> for [S], these don't conflict because
str is never Sized.
This commit does two things: it adds an example for indexing vectors, and it changes the \"Examples\" section to use full sentences.
This change was spurred by someone in the #rust IRC channel asking if there was a `.set()` method for changing the `i`-th value of a vector (they had missed that `Vec` implements `IndexMut`, which is easy to do if you're not aware of that trait).
This makes the `bit::vec::bench::bench_bit_vec_big_union` benchmark go
from `774 ns/iter (+/- 190)` to `602 ns/iter (+/- 5)`.
(There's room for more work here too: if one can guarantee 128-bit
alignment for the vector, the compiler actually optimises `union`,
`intersection` etc. to SIMD instructions, which end up being ~5x faster
that the original version, and 4x faster than the optimised version in
this patch.)
This makes the `bit::vec::bench::bench_bit_vec_big_union` benchmark go
from `774 ns/iter (+/- 190)` to `602 ns/iter (+/- 5)`.
(There's room for more work here too: if one can guarantee 128-bit
alignment for the vector, the compiler actually optimises `union`,
`intersection` etc. to SIMD instructions, which end up being ~5x faster
that the original version, and 4x faster than the optimised version in
this patch.)
collections: Implement String::drain(range) according to RFC 574
`.drain(range)` is unstable and under feature(collections_drain).
This adds a safe way to remove any range of a String as efficiently as
possible.
As noted in the code, this drain iterator has none of the memory safety
issues of the vector version.
RFC tracking issue is #23055
These implementations were intended to be unstable, but currently the stability
attributes cannot handle a stable trait with an unstable `impl` block. This
commit also audits the rest of the standard library for explicitly-`#[unstable]`
impl blocks. No others were removed but some annotations were changed to
`#[stable]` as they're defacto stable anyway.
One particularly interesting `impl` marked `#[stable]` as part of this commit
is the `Add<&[T]>` impl for `Vec<T>`, which uses `push_all` and implicitly
clones all elements of the vector provided.
Closes#24791
[breaking-change]
`.drain(range)` is unstable and under feature(collections_drain).
This adds a safe way to remove any range of a String as efficiently as
possible.
As noted in the code, this drain iterator has none of the memory safety
issues of the vector version.
RFC tracking issue is #23055
These implementations were intended to be unstable, but currently the stability
attributes cannot handle a stable trait with an unstable `impl` block. This
commit also audits the rest of the standard library for explicitly-`#[unstable]`
impl blocks. No others were removed but some annotations were changed to
`#[stable]` as they're defacto stable anyway.
One particularly interesting `impl` marked `#[stable]` as part of this commit
is the `Add<&[T]>` impl for `Vec<T>`, which uses `push_all` and implicitly
clones all elements of the vector provided.
Closes#24791
Implement Vec::drain(\<range type\>) from rust-lang/rfcs#574, tracking issue #23055.
This is a big step forward for vector usability. This is an introduction of an API for removing a range of *m* consecutive elements from a vector, as efficently as possible.
New features:
- Introduce trait `std::collections::range::RangeArgument` implemented by all four built-in range types.
- Change `Vec::drain()` to use `Vec::drain<R: RangeArgument>(R)`
Implementation notes:
- Use @Gankro's idea for memory safety: Use `set_len` on the source vector when creating the iterator, to make sure that the part of the vector that will be modified is unreachable. Fix up things in Drain's destructor — but even if it doesn't run, we don't expose any moved-out-from slots of the vector.
- This `.drain<R>(R)` very close to how it is specified in the RFC.
- Introduced as unstable
- Drain reuses the slice iterator — copying and pasting the same iterator pointer arithmetic again felt very bad
- The `usize` index as a range argument in the RFC is not included. The ranges trait would have to change to accomodate it.
Please help me with:
- Name and location of the new ranges trait.
- Design of the ranges trait
- Understanding Niko's comments about variance (Note: for a long time I was using a straight up &mut Vec in the iterator, but I changed this to permit reusing the slice iterator).
Previous PR and discussion: #23071
Improve example for as_string and add example for as_vec
Provide a better example of `as_string` / `DerefString`'s unique capabilities.
Use an example where (for an unspecified reason) you need a &String, and
show how `as_string` solves the problem without needing an allocation.
Changes the style guidelines regarding unit tests to recommend using a
sub-module named "tests" instead of "test" for unit tests as "test"
might clash with imports of libtest.
This is an implementation of [RFC 1030][rfc] which adds these traits to the
prelude and additionally removes all inherent `into_iter` methods on collections
in favor of the trait implementation (which is now accessible by default).
[rfc]: https://github.com/rust-lang/rfcs/pull/1030
This is technically a breaking change due to the prelude additions and removal
of inherent methods, but it is expected that essentially no code breaks in
practice.
[breaking-change]
Closes#24538
as accepted in [RFC 526](https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md).
Note that this brand new method is marked as **stable**. I judged this safe enough: it’s simple enough that it’s very unlikely to change. Still, I can mark it unstable instead if you prefer.
r? @alexcrichton
For now, words() is left in (but deprecated), and Words is a type alias for
struct SplitWhitespace.
Also cleaned up references to s.words() throughout codebase.
Closes#15628
This commit removes all the old casting/generic traits from `std::num` that are
no longer in use by the standard library. This additionally removes the old
`strconv` module which has not seen much use in quite a long time. All generic
functionality has been supplanted with traits in the `num` crate and the
`strconv` module is supplanted with the [rust-strconv crate][rust-strconv].
[rust-strconv]: https://github.com/lifthrasiir/rust-strconv
This is a breaking change due to the removal of these deprecated crates, and the
alternative crates are listed above.
[breaking-change]
This implementation is currently about 3-4 times faster than using the `.to_string()` based approach.
I would also suggest we deprecate `String::from_str` since it's redundant with the stable `String::from` method, but I'll leave that for a future PR.
It's just as convenient, but it's much faster. Using write! requires an
extra call to fmt::write and a extra dynamically dispatched call to
Arguments' Display format function.
This is an implementation of [RFC 1030][rfc] which adds these traits to the
prelude and additionally removes all inherent `into_iter` methods on collections
in favor of the trait implementation (which is now accessible by default).
[rfc]: https://github.com/rust-lang/rfcs/pull/1030
This is technically a breaking change due to the prelude additions and removal
of inherent methods, but it is expected that essentially no code breaks in
practice.
[breaking-change]
Closes#24538
It's just as convenient, but it's much faster. Using write! requires an
extra call to fmt::write and a extra dynamically dispatched call to
Arguments' Display format function.
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
The meaning of each variant of this enum was somewhat ambiguous and it's uncler
that we wouldn't even want to add more enumeration values in the future. As a
result this error has been altered to instead become an opaque structure.
Learning about the "first invalid byte index" is still an unstable feature, but
the type itself is now stable.
Right now, if the user requests to increase the vector size via reserve() or push_back() and the request brings the attempted memory above usize::MAX, we panic.
With this change there is only a panic if the minimum requested memory that could meet the requirement is above usize::MAX- otherwise it simply requests its largest capacity possible, usize::MAX.
