about summary refs log tree commit diff
path: root/src/liballoc/string.rs
AgeCommit message (Collapse)AuthorLines
2020-03-30Optimize strip_prefix and strip_suffix with str patternsNikhil Benesch-0/+15
Constructing a Searcher in strip_prefix and strip_suffix is unnecessarily slow when the pattern is a fixed-length string. Add strip_prefix and strip_suffix methods to the Pattern trait, and add optimized implementations of these methods in the str implementation. The old implementation is retained as the default for these methods.
2020-03-24must_use on split_offKornel-0/+1
#70194
2020-03-15Rollup merge of #69661 - lopopolo:string-from-mut-str, r=sfacklerMazdak Farrokhzad-0/+11
Implement From<&mut str> for String I ran into this missing impl when trying to do `String::from` on the result returned from this API in the `uuid` crate: https://docs.rs/uuid/0.8.1/uuid/adapter/struct.Hyphenated.html#method.encode_lower I wasn't sure what to put in the stability annotation. I'd appreciate some help with that :)
2020-03-10Add docs for From::<&mut str>::from String implRyan Lopopolo-0/+3
2020-03-10Add stable feature nameRyan Lopopolo-1/+1
2020-03-05Fixed a typoTrolledWoods-1/+1
"vector" was used instead of "string"
2020-03-02Implement From<&mut str> for StringRyan Lopopolo-0/+8
2020-02-19Change FromStr for String to use Infallible directlyPeter Todd-11/+4
Fixes the confusing documentation on `ParseError` by making it irrelevant.
2020-02-09Rollup merge of #68742 - tspiteri:string-as-mut, r=sfacklerJonas Schievink-0/+8
implement AsMut<str> for String Closes #68741.
2020-02-01implement AsMut<str> for StringTrevor Spiteri-0/+8
2020-02-02Derive Clone + PartialEq + Eq for std::string::FromUtf8Errorkennytm-1/+1
2019-12-22Format the worldMark Rousskov-59/+54
2019-12-18Propagate cfg bootstrapMark Rousskov-4/+1
2019-12-13Require stable/unstable annotations for the constness of all stable ↵Oliver Scherer-0/+4
functions with a `const` modifier
2019-11-07Rollup merge of #66111 - RalfJung:from_raw_parts, r=CentrilYuki Okushi-1/+1
improve from_raw_parts docs Triggered by https://github.com/rust-lang/rfcs/pull/2806. Hopefully this helps clarify that joining slices across allocations is not possible in Rust currently. r? @Centril
2019-11-05also edit String::from_raw_parts while we are at itRalf Jung-1/+1
2019-11-01doc(str): show example of chars().count() under len()Jeff Dickey-2/+7
the docs are great at explaining that .len() isn't like in other languages but stops short of explaining how to get the character length. r? @steveklabnik
2019-10-25Add {String,Vec}::into_raw_partsJake Goulding-0/+33
2019-10-25Use ManuallyDrop in examples for {Vec,String}::from_raw_partsJake Goulding-7/+9
2019-10-25Remove unneeded pointer castingJake Goulding-6/+6
2019-10-01Remove unneeded `fn main` blocks from docsLzu Tao-4/+2
2019-09-25Snap cfgs to new betaMark Rousskov-1/+0
2019-09-24fix several issues in String docsjordins-4/+4
- In some places &str was shown instead of String. - into_bytes is the reverse of from_utf8 Fixes #63797
2019-09-16Const-stabilize `String::new`.Mazdak Farrokhzad-1/+1
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-14 02:10:52 +0000