about summary refs log tree commit diff
path: root/src/liballoc/string.rs
AgeCommit message (Collapse)AuthorLines
2019-08-16Rename CollectionAllocError to TryReserveErrorSimon Sapin-7/+7
2019-07-28Deny `unused_lifetimes` through rustbuildVadim Petrochenkov-0/+2
2019-07-05Rollup merge of #62123 - jeremystucki:needless_lifetimes_std, r=alexcrichtonMazdak Farrokhzad-1/+1
Remove needless lifetimes (std) Split from #62039
2019-07-02When possible without changing semantics, implement Iterator::last in terms ↵Kyle Huey-0/+5
of DoubleEndedIterator::next_back for types in liballoc and libcore. Provided that the iterator has finite length and does not trigger user-provided code, this is safe. What follows is a full list of the DoubleEndedIterators in liballoc/libcore and whether this optimization is safe, and if not, why not. src/liballoc/boxed.rs Box: Pass through to avoid defeating optimization of the underlying DoubleIterator implementation. This has no correctness impact. src/liballoc/collections/binary_heap.rs Iter: Pass through to avoid defeating optimizations on slice::Iter IntoIter: Not safe, changes Drop order Drain: Not safe, changes Drop order src/liballoc/collections/btree/map.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order Keys: Safe to call next_back, invokes no user defined code. Values: ditto ValuesMut: ditto Range: ditto RangeMut: ditto src/liballoc/collections/btree/set.rs Iter: Safe to call next_back, invokes no user defined code. IntoIter: Not safe, changes Drop order Range: Safe to call next_back, invokes no user defined code. src/liballoc/collections/linked_list.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order src/liballoc/collections/vec_deque.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order Drain: ditto src/liballoc/string.rs Drain: Safe because return type is a primitive (char) src/liballoc/vec.rs IntoIter: Not safe, changes Drop order Drain: ditto Splice: ditto src/libcore/ascii.rs EscapeDefault: Safe because return type is a primitive (u8) src/libcore/iter/adapters/chain.rs Chain: Not safe, invokes user defined code (Iterator impl) src/libcore/iter/adapters/flatten.rs FlatMap: Not safe, invokes user defined code (Iterator impl) Flatten: ditto FlattenCompat: ditto src/libcore/iter/adapters/mod.rs Rev: Not safe, invokes user defined code (Iterator impl) Copied: ditto Cloned: Not safe, invokes user defined code (Iterator impl and T::clone) Map: Not safe, invokes user defined code (Iterator impl + closure) Filter: ditto FilterMap: ditto Enumerate: Not safe, invokes user defined code (Iterator impl) Skip: ditto Fuse: ditto Inspect: ditto src/libcore/iter/adapters/zip.rs Zip: Not safe, invokes user defined code (Iterator impl) src/libcore/iter/range.rs ops::Range: Not safe, changes Drop order, but ALREADY HAS SPECIALIZATION ops::RangeInclusive: ditto src/libcore/iter/sources.rs Repeat: Not safe, calling last should iloop. Empty: No point, iterator is at most one item long. Once: ditto OnceWith: ditto src/libcore/option.rs Item: No point, iterator is at most one item long. Iter: ditto IterMut: ditto IntoIter: ditto src/libcore/result.rs Iter: No point, iterator is at most one item long IterMut: ditto IntoIter: ditto src/libcore/slice/mod.rs Split: Not safe, invokes user defined closure SplitMut: ditto RSplit: ditto RSplitMut: ditto Windows: Safe, already has specialization Chunks: ditto ChunksMut: ditto ChunksExact: ditto ChunksExactMut: ditto RChunks: ditto RChunksMut: ditto RChunksExact: ditto RChunksExactMut: ditto src/libcore/str/mod.rs Chars: Safe, already has specialization CharIndices: ditto Bytes: ditto Lines: Safe to call next_back, invokes no user defined code. LinesAny: Deprecated Everything that is generic over P: Pattern: Not safe because Pattern invokes user defined code. SplitWhitespace: Safe to call next_back, invokes no user defined code. SplitAsciiWhitespace: ditto
2019-07-01Remove needless lifetimesJeremy Stucki-1/+1
2019-05-22Revert "Add implementations of last in terms of next_back on a bunch of ↵Steven Fackler-4/+0
DoubleEndedIterators." This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
2019-05-16Rollup merge of #59825 - jsgf:from-ref-string, r=sfacklerMazdak Farrokhzad-0/+8
string: implement From<&String> for String Allow Strings to be created from borrowed Strings. This is mostly to make things like passing `&String` to an `impl Into<String>` parameter frictionless. Fixes #59827.
2019-05-14Rollup merge of #60130 - khuey:efficient_last, r=sfacklerMazdak Farrokhzad-0/+4
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators. I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so. The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
2019-05-10Add examples of ordered retainJosh Stone-0/+10
2019-04-29Document the order of {Vec,VecDeque,String}::retainJosh Stone-2/+2
It's natural for `retain` to work in order from beginning to end, but this wasn't actually documented to be the case. If we actually promise this, then the caller can do useful things like track the index of each element being tested, as [discussed in the forum][1]. This is now documented for `Vec`, `VecDeque`, and `String`. [1]: https://users.rust-lang.org/t/vec-retain-by-index/27697 `HashMap` and `HashSet` also have `retain`, and the `hashbrown` implementation does happen to use a plain `iter()` order too, but it's not certain that this should always be the case for these types.
2019-04-19Add implementations of last in terms of next_back on a bunch of ↵Kyle Huey-0/+4
DoubleEndedIterators. r?Manishearth
2019-04-09string: implement From<&String> for StringJeremy Fitzhardinge-0/+8
Allow Strings to be created from borrowed Strings. This is mostly to make things like passing &String to an `impl Into<String>` parameter frictionless.
2019-03-09Use lifetime contravariance to elide more lifetimes in core+alloc+stdScott McMurray-2/+2
2019-02-13Add a convert::Infallible empty enum, make string::ParseError an aliasSimon Sapin-34/+3
2019-02-10libs: doc commentsAlexander Regueiro-4/+2
2019-02-03liballoc: revert nested imports style changes.Mazdak Farrokhzad-24/+14
2019-02-02liballoc: fix some idiom lints.Mazdak Farrokhzad-8/+8
2019-02-02liballoc: elide some lifetimes.Mazdak Farrokhzad-10/+10
2019-02-02liballoc: prefer imports of borrow from libcore.Mazdak Farrokhzad-1/+1
2019-02-02liballoc: adjust abolute imports + more import fixes.Mazdak Farrokhzad-1/+1
2019-02-02liballoc: refactor & fix some imports.Mazdak Farrokhzad-15/+24
2019-02-02liballoc: cargo check passes on 2018Mazdak Farrokhzad-5/+5
2018-12-25Remove licensesMark Rousskov-10/+0
2018-12-09Fix typoBeatButton-1/+1
2018-12-06Rollup merge of #56548 - Lucretiel:string-extend-optimize, r=sfacklerPietro Albini-18/+29
Optimized string FromIterator + Extend impls I noticed that there was a lost opportunity to reuse string buffers in `FromIterator<String>` and `FromIterator<Cow<str>>`; updated the implementations to use these. In practice this translates to at least one fewer allocation when using these APIs. Additionally, rewrote `Extend` implementations to use `iter.for_each`, which (supposedly) helps the compiler optimize those loops (because iterator adapters are encouraged to provide optimized implementations of `fold` and `try_fold`.
2018-12-05Added explainatory commentsNathan West-0/+6
2018-12-05Fixed mutabilityNathan West-4/+4
2018-12-05Optimized string FromIterator implsNathan West-18/+23
2018-12-04cleanup: remove static lifetimes from constsljedrz-1/+1
2018-12-02Update issue number of `shrink_to` methods to point the tracking issueHidehito Yabuuchi-1/+1
2018-11-21String: add a FIXME to from_utf16ljedrz-0/+2
2018-11-15Rollup merge of #55530 - ljedrz:speed_up_String_from_utf16, r=SimonSapinPietro Albini-1/+9
Speed up String::from_utf16 Collecting into a `Result` is idiomatic, but not necessarily fast due to rustc not being able to preallocate for the resulting collection. This is fine in case of an error, but IMO we should optimize for the common case, i.e. a successful conversion. This changes the behavior of `String::from_utf16` from collecting into a `Result` to pushing to a preallocated `String` in a loop. According to [my simple benchmark](https://gist.github.com/ljedrz/953a3fb74058806519bd4d640d6f65ae) this change makes `String::from_utf16` around **twice** as fast.
2018-11-11Minor style guide corrections.Denis Vasilik-6/+6
2018-11-11Whitespace cleanup according to Rust's style guidelines.Denis Vasilik-3/+3
2018-11-11Added comments for trait implementations.Denis Vasilik-1/+28
2018-11-11Added comment for From trait implementation: boxed string slice to StringDenis Vasilik-0/+14
2018-11-07Rollup merge of #55734 - teresy:shorthand-fields, r=davidtwcokennytm-1/+1
refactor: use shorthand fields refactor: use shorthand for single fields everywhere (excluding tests).
2018-11-06refactor: use shorthand fieldsteresy-1/+1
2018-10-31Speed up String::from_utf16ljedrz-1/+9
2018-10-27Update string.rsHsiang-Cheng Yang-1/+1
remove unused variable i in example String::with_capacity()
2018-09-27liballoc: mark str.to_owned() and String::from(&str) as #[inline].Matthias Krüger-0/+1
Fixes #53681
2018-09-06Fix invalid urlsGuillaume Gomez-3/+1
2018-08-22docs: std::string::String.repeat(): slightly rephrase to be more in-line ↵Matthias Krüger-3/+3
with other descriptions. add ticks around a few keywords in other descriptions.
2018-08-20Replace usages of ptr::offset with ptr::{add,sub}.Corey Farwell-7/+7
2018-08-11Add links to std::char::REPLACEMENT_CHARACTER from docs.Corey Farwell-2/+4
There are a few places where we mention the replacement character in the docs, and it could be helpful for users to utilize the constant which is available in the standard library, so let’s link to it!
2018-07-22Rollup merge of #51807 - newpavlov:deprecate_str_slice, r=alexcrichtonkennytm-1/+1
Deprecation of str::slice_unchecked(_mut) Closes #51715 I am not sure if 1.28.0 or 1.29.0 should be used for deprecation version, for now it's 1.28.0. Additionally I've replaced `slice_unchecked` uses with `get_unchecked`. The only places where this method is still used are `src/liballoc/tests/str.rs` and `src/liballoc/tests/str.rs`.
2018-06-29Move core::alloc::CollectionAllocErr to alloc::collectionsSimon Sapin-1/+1
2018-06-26Deprecation of str::slice_uncheked(_mut)newpavlov-1/+1
2018-05-24stabilize RangeBounds collections_range #30877Cory Sherman-4/+4
rename RangeBounds::start() -> start_bound() rename RangeBounds::end() -> end_bound()
2018-05-17Rollup merge of #50170 - burtonageo:more_cow_from, r=alexcrichtonkennytm-0/+8
Implement From for more types on Cow This is basically https://github.com/rust-lang/rust/pull/48191, except that it should be implemented in a way that doesn't break third party crates.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-15 15:10:14 +0000