summary refs log tree commit diff
path: root/library/alloc/src/string.rs
AgeCommit message (Collapse)AuthorLines
2021-06-09Rollup merge of #85715 - fee1-dead:document-string, r=JohnTitorYuki Okushi-7/+43
Document `From` impls in string.rs
2021-06-06String::remove_matches O(n^2) -> O(n)Tamir Duberstein-15/+38
Copy only non-matching bytes.
2021-06-06Use iter::from_fn in String::remove_matchesTamir Duberstein-9/+3
2021-05-29Add `String::extend_from_within`Waffle-0/+36
This patch adds `String::extend_from_within` function under the `string_extend_from_within` feature gate similar to the `Vec::extend_from_within` function.
2021-05-26Document `From` impls in string.rsDeadbeef-7/+43
2021-05-17Optimize default ToString implMark Rousskov-2/+3
This avoids a zero-length write_str call, which boils down to a zero-length memmove and ultimately costs quite a few instructions on some workloads. This is approximately a 0.33% instruction count win on diesel-check.
2021-05-05alloc: Add unstable Cfg feature `no-global_oom_handling`John Ericson-5/+75
For certain sorts of systems, programming, it's deemed essential that all allocation failures be explicitly handled where they occur. For example, see Linus Torvald's opinion in [1]. Merely not calling global panic handlers, or always `try_reserving` first (for vectors), is not deemed good enough, because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc`, rolling their own allocation abstractions. But this would, in my opinion be a real shame. `alloc` has a few `try_*` methods already, and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature, but there are currently uncertainties around how std library crate's Cargo features may or not be stable, so to avoid any risk of stabilizing by mistake we are going with a more low-level "raw cfg" token, which cannot be interacted with via Cargo alone. Note also that since there is no notion of "default cfg tokens" outside of Cargo features, we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility), but it doesn't matter for raw cfg tokens which are not intended to be "constraint solved" by Cargo or anything else. To support this use-case we create a new feature, "global-oom-handling", on by default, and put the global OOM handler infra and everything else it that depends on it behind it. By default, nothing is changed, but users concerned about global handling can make sure it is disabled, and be confident that all OOM handling is local and explicit. For this first iteration, non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods, but are kept anyways since they can be oom-safely created "from parts", and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/
2021-05-03Fix stability attributes of byte-to-string specializationLingMan-2/+2
2021-05-02Auto merge of #82576 - gilescope:to_string, r=Amanieubors-0/+41
i8 and u8::to_string() specialisation (far less asm). Take 2. Around 1/6th of the assembly to without specialisation. https://godbolt.org/z/bzz8Mq (partially fixes #73533 )
2021-03-22Rollup merge of #82554 - SkiFire13:fix-string-retain-unsoundness, r=m-ou-seDylan DPC-15/+22
Fix invalid slice access in String::retain As noted in #78499, the previous fix was technically still unsound because it accessed elements of a slice outside its bounds (even though they were still inside the same allocation). This PR addresses that concern by switching to a dropguard approach.
2021-03-21Auto merge of #83053 - oli-obk:const_stab_version, r=m-ou-sebors-1/+1
Fix const stability `since` versions. fixes #82085 r? `@m-ou-se`
2021-03-19Auto merge of #71780 - jcotton42:string_remove_matches, r=joshtriplettbors-0/+56
Implement String::remove_matches Closes #50206. I lifted the function help from `@frewsxcv's` original PR (#50015), hope they don't mind. I'm also wondering whether it would be useful for `remove_matches` to collect up the removed substrings into a `Vec` and return them, right now they're just overwritten by the copy and lost.
2021-03-15Fix const stability `since` versions.Oli Scherer-1/+1
2021-03-08Closer similarities.Giles Cope-26/+16
2021-03-08Update library/alloc/src/string.rsSquirrel-6/+3
Co-authored-by: LingMan <LingMan@users.noreply.github.com>
2021-03-07Add documentation for string->Cow conversionsMichael Howell-0/+33
Mostly, it's just to reassure everyone that these functions don't allocate. Part of #51430
2021-03-07vec![0;4] is a fast path.Giles Cope-22/+20
After much tweaking found a way to get similar asm size as the u8 to_string implementation.
2021-03-05Implement String::remove_matchesJosh Cotton-0/+56
2021-03-04less uB in i8Giles Cope-2/+6
2021-03-04Alternative LUT rather than dividing.Giles Cope-1/+34
2021-02-27u8::to_string() specialisation (far less asm).Giles Cope-0/+19
2021-02-26Fix invalid slice access in String::retainGiacomo Stevanato-15/+22
2021-02-25Convert primitives to use intra-doc linksJoshua Nelson-1/+1
2021-02-23Rollup merge of #82128 - anall:feature/add_diagnostic_items, r=davidtwcoDylan DPC-0/+1
add diagnostic items for OsString/PathBuf/Owned as well as to_vec on slice This is adding diagnostic items to be used by rust-lang/rust-clippy#6730, but my understanding is the clippy-side change does need to be done over there since I am adding a new clippy feature. Add diagnostic items to the following types: OsString (os_string_type) PathBuf (path_buf_type) Owned (to_owned_trait) As well as the to_vec method on slice/[T]
2021-02-16a few more diagnostic itemsAndrea Nall-0/+1
2021-02-12Rename `Range::ensure_subset_of` to `slice::range`dylni-2/+3
2021-02-12Fix possible soundness issue in `ensure_subset_of`dylni-1/+1
2021-02-12Improve design of `assert_len`dylni-2/+2
2021-01-31Fix small typoSebastian Widua-1/+1
2021-01-26shrink_to shouldn't panic on len greater than capacityThom Wiggers-2/+1
2021-01-22Add doc aliases for memory allocationsYoshua Wuyts-0/+2
- Vec::with_capacity / Box::new -> alloc + malloc - Box::new_zeroed -> calloc - Vec::{reserve,reserve_exact,try_reserve_exact,shrink_to_fit,shrink_to} -> realloc
2021-01-18Fix soundness issue for `replace_range` and `range`dylni-3/+10
2020-12-28Add "length" as doc alias to len methodsKonrad Borowski-0/+1
2020-12-09Clarify that String::split_at takes a byte index.Corey Farwell-1/+1
2020-10-29Prevent String::retain from creating non-utf8 strings when abusing panicGiacomo Stevanato-4/+6
2020-10-22Clean up lib docsCamelid-9/+10
2020-10-18Auto merge of #76885 - dylni:move-slice-check-range-to-range-bounds, r=KodrAusbors-3/+2
Move `slice::check_range` to `RangeBounds` Since this method doesn't take a slice anymore (#76662), it makes more sense to define it on `RangeBounds`. Questions: - Should the new method be `assert_len` or `assert_length`?
2020-10-16Remove shrink_to_fit from default ToString::to_string implementation.Mara Bos-1/+0
Co-authored-by: scottmcm <scottmcm@users.noreply.github.com>
2020-09-19Rollup merge of #76525 - fusion-engineering-forks:string-drain, r=dtolnayRalf Jung-1/+35
Add as_str() to string::Drain. Vec's Drain recently [had its `.as_slice()` stabilized](https://github.com/rust-lang/rust/pull/72584), but String's Drain was still missing the analogous `.as_str()`. This adds that. Also improves the Debug implementation, which now shows the remaining data instead of just `"Drain { .. }"`.
2020-09-19Add tracking issue number for string_drain_as_str.Mara Bos-3/+3
2020-09-18Rename method to `assert_len`dylni-2/+2
2020-09-18Move `slice::check_range` to `RangeBounds`dylni-3/+2
2020-09-15fix slice::check_range aliasing problemsRalf Jung-1/+2
2020-09-09Disable AsRef implementations for String's Drain.Mara Bos-14/+15
Since trait implementations cannot be unstable, we should only add them when the as_str feature gets stabilized. Until then, only `.as_str()` is available (behind a feature gate).
2020-09-09Mark AsRef impls for String's Drain as stable.Mara Bos-2/+2
Trait implementations effectively can't be #[unstable].
2020-09-09Add AsRef<[u8]> for String's Drain.Mara Bos-0/+7
2020-09-09Show remaining data in string::Drain's Debug impl.Mara Bos-1/+1
2020-09-09Add as_str() and AsRef to string::Drain.Mara Bos-0/+26
2020-09-04Auto merge of #75207 - dylni:add-slice-check-range, r=KodrAusbors-14/+6
Add `slice::check_range` This method is useful for [`RangeBounds`] parameters. It's even been [rewritten](https://github.com/rust-lang/rust/blob/22ee68dc586440f96b76b32fbd6087507c6afdb9/src/librustc_data_structures/sorted_map.rs#L214) [many](https://github.com/rust-lang/rust/blob/22ee68dc586440f96b76b32fbd6087507c6afdb9/library/alloc/src/vec.rs#L1299) [times](https://github.com/rust-lang/rust/blob/22ee68dc586440f96b76b32fbd6087507c6afdb9/library/core/src/slice/mod.rs#L2441) in the standard library, sometimes assuming that the bounds won't be [`usize::MAX`]. For example, [`Vec::drain`] creates an empty iterator when [`usize::MAX`] is used as an inclusive end bound: ```rust assert!(vec![1].drain(..=usize::max_value()).eq(iter::empty())); ``` If this PR is merged, I'll create another to use it for those methods. [`RangeBounds`]: https://doc.rust-lang.org/std/ops/trait.RangeBounds.html [`usize::MAX`]: https://doc.rust-lang.org/std/primitive.usize.html#associatedconstant.MAX [`Vec::drain`]: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.drain
2020-08-23Convert from str -> prim@str for `alloc`Joshua Nelson-5/+7
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-02 13:45:22 +0000