about summary refs log tree commit diff
path: root/src/libcore/str
AgeCommit message (Collapse)AuthorLines
2018-08-04Remove explicit returns where unnecessaryljedrz-2/+2
2018-08-04deleted changed linesredroc-33/+0
2018-08-04fixed broken links to charredroc-19/+19
2018-08-02Add #![feature(trim_direction)] to doc commentsvarkor-2/+14
2018-08-02Add trim_start, trim_end, trim_start_matches and trim_end_matchesvarkor-13/+159
2018-07-23libcore: Prefer `Option::map` over `match` where applicableColin Wallace-7/+4
2018-07-22Rollup merge of #51807 - newpavlov:deprecate_str_slice, r=alexcrichtonkennytm-14/+16
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-07-13Change RangeInclusive to a three-field struct.kennytm-10/+10
Fix #45222.
2018-07-12deprecation message improvementArtyom Pavlov-2/+2
2018-06-27Add str::split_ascii_whitespace.Clar Charr-4/+155
2018-06-26review fixArtyom Pavlov-2/+2
2018-06-26migrate codebase to `..=` inclusive range patternsZack M. Davis-14/+14
These were stabilized in March 2018's #47813, and are the Preferred Way to Do It going forward (q.v. #51043).
2018-06-26Deprecation of str::slice_uncheked(_mut)newpavlov-14/+16
2018-06-03impl Default for &mut strkennytm-0/+6
2018-05-28get rid of str::from_raw_parts_mutRalf Jung-31/+5
str::from_raw_parts has been removed long ago because it can be obtained via str::from_utf8_unchecked and slice::from_raw_parts. The same goes for str::from_raw_parts_mut.
2018-05-28extend from_raw_parts docs for slices and strs to mention alignment requirementRalf Jung-6/+4
2018-05-23move type def out of unsafe blockJoe ST-6/+4
from https://github.com/rust-lang/rust/pull/50863#discussion_r190213000 move the union definition outside of the unsafe block
2018-05-21Make `[T]::len` and `str::len` const fnOliver Schneider-5/+15
2018-05-17Switch to 1.26 bootstrap compilerMark Simulacrum-475/+115
2018-04-30Clean up the other Slice*Inclusive impls for strMichael Lamparski-24/+10
A previous PR fixed one method that was legitimately buggy; this cleans up the rest to be less diverse, mirroring the corresponding impls on [T] to the greatest extent possible without introducing any unnecessary UTF-8 boundary checks at 0.
2018-04-30str/slice: factor out overflow error messagesMichael Lamparski-8/+10
2018-04-22Auto merge of #49896 - SimonSapin:inherent, r=alexcrichtonbors-17/+1753
Add inherent methods in libcore for [T], [u8], str, f32, and f64 # Background Primitive types are defined by the language, they don’t have a type definition like `pub struct Foo { … }` in any crate. So they don’t “belong” to any crate as far as `impl` coherence is concerned, and on principle no crate would be able to define inherent methods for them, without a trait. Since we want these types to have inherent methods anyway, the standard library (with cooperation from the compiler) bends this rule with code like [`#[lang = "u8"] impl u8 { /*…*/ }`](https://github.com/rust-lang/rust/blob/1.25.0/src/libcore/num/mod.rs#L2244-L2245). The `#[lang]` attribute is permanently-unstable and never intended to be used outside of the standard library. Each lang item can only be defined once. Before this PR there is one impl-coherence-rule-bending lang item per primitive type (plus one for `[u8]`, which overlaps with `[T]`). And so one `impl` block each. These blocks for `str`, `[T]` and `[u8]` are in liballoc rather than libcore because *some* of the methods (like `<[T]>::to_vec(&self) -> Vec<T> where T: Clone`) need a global memory allocator which we don’t want to make a requirement in libcore. Similarly, `impl f32` and `impl f64` are in libstd because some of the methods are based on FFI calls to C’s `libm` and we want, as much as possible, libcore not to require “runtime support”. In libcore, the methods of `str` and `[T]` that don’t allocate are made available through two **unstable traits** `StrExt` and `SliceExt` (so the traits can’t be *named* by programs on the Stable release channel) that have **stable methods** and are re-exported in the libcore prelude (so that programs on Stable can *call* these methods anyway). Non-allocating `[u8]` methods are not available in libcore: https://github.com/rust-lang/rust/issues/45803. Some `f32` and `f64` methods are in an unstable `core::num::Float` trait with stable methods, but that one is **not in the libcore prelude**. (So as far as Stable programs are concerns it doesn’t exist, and I don’t know what the point was to mark these methods `#[stable]`.) https://github.com/rust-lang/rust/issues/32110 is the tracking issue for these unstable traits. # High-level proposal Since the standard library is already bending the rules, why not bend them *a little more*? By defining a few additional lang items, the compiler can allow the standard library to have *two* `impl` blocks (in different crates) for some primitive types. The `StrExt` and `SliceExt` traits still exist for now so that we can bootstrap from a previous-version compiler that doesn’t have these lang items yet, but they can be removed in next release cycle. (`Float` is used internally and needs to be public for libcore unit tests, but was already `#[doc(hidden)]`.) I don’t know if https://github.com/rust-lang/rust/issues/32110 should be closed by this PR, or only when the traits are entirely removed after we make a new bootstrap compiler. # Float methods Among the methods of the `core::num::Float` trait, three are based on LLVM intrinsics: `abs`, `signum`, and `powi`. PR https://github.com/rust-lang/rust/pull/27823 “Remove dependencies on libm functions from libcore” moved a bunch of `core::num::Float` methods back to libstd, but left these three behind. However they aren’t specifically discussed in the PR thread. The `compiler_builtins` crate defines `__powisf2` and `__powidf2` functions that look like implementations of `powi`, but I couldn’t find a connection with the `llvm.powi.f32` and `llvm.powi.f32` intrinsics by grepping through LLVM’s code. In discussion starting at https://github.com/rust-lang/rust/issues/32110#issuecomment-370647922 Alex says that we do not want methods in libcore that require “runtime support”, but it’s not clear whether that applies to these `abs`, `signum`, or `powi`. In doubt, I’ve **removed** them for the trait and moved them to inherent methods in libstd for now. We can move them back later (or in this PR) if we decide that’s appropriate. # Change details For users on the Stable release channel: * I believe this PR does not make any breaking change * Some methods for `[u8]`, `f32`, and `f64` are newly available to `#![no_std]` users (fixes https://github.com/rust-lang/rust/issues/45803) * There should be no visible change for `std` users in terms of what programs compile or what their behavior is. (Only in compiler error messages, possibly.) For Nightly users, additionally: * The unstable `StrExt` and `SliceExt` traits are gone * Their methods are now inherent methods of `str` and `[T]` (so only code that explicitly named the traits should be affected, not "normal" method calls) * The `abs`, `signum` and `powi` methods of the `Float` trait are gone * The `Float` trait’s unstable feature name changed to `float_internals` with no associated tracking issue, to reflect it being a permanently unstable implementation detail rather than a public API on a path to stabilization. * Its remaining methods are now inherent methods of `f32` and `f64`. ----- CC @rust-lang/libs for the API changes, @rust-lang/compiler for the new lang items
2018-04-21Make the unstable StrExt and SliceExt traits private to libcore in not(stage0)Simon Sapin-3/+5
`Float` still needs to be public for libcore unit tests.
2018-04-21Replace StrExt with inherent str methods in libcoreSimon Sapin-14/+1748
2018-04-17smaller PR just to fix #50002Michael Lamparski-7/+2
2018-04-16Remove unwanted auto-linking and updateGuillaume Gomez-1/+1
2018-04-12Merge core::unicode::str into core::strSimon Sapin-1/+115
And the UnicodeStr trait into StrExt
2018-04-12Move Utf8Lossy decoder to libcoreSimon Sapin-0/+216
2018-03-17Add an example of lossy decoding to str::Utf8Error docsSimon Sapin-0/+31
2018-03-15Stabilize `inclusive_range` library feature.kennytm-18/+6
Stabilize std::ops::RangeInclusive and std::ops::RangeInclusiveTo.
2018-03-03core: Update stability attributes for FusedIteratorUlrik Sverdrup-7/+7
2018-03-03core: Stabilize FusedIteratorUlrik Sverdrup-7/+7
FusedIterator is a marker trait that promises that the implementing iterator continues to return `None` from `.next()` once it has returned `None` once (and/or `.next_back()`, if implemented). The effects of FusedIterator are already widely available through `.fuse()`, but with stable `FusedIterator`, stable Rust users can implement this trait for their iterators when appropriate.
2018-02-15spelling fix in commentSteve Klabnik-1/+1
2018-01-06Make double ended string searchers use dependent fingers (fixes #47175)Manish Goregaokar-6/+10
2018-01-05Rollup merge of #47030 - ollie27:stab, r=alexcrichtonkennytm-2/+6
Correct a few stability attributes * The extra impls for `ManuallyDrop` were added in #44310 which was only stabilised in 1.22.0. * The impls for `SliceIndex` were stabilised in #43373 but as `RangeInclusive` and `RangeToInclusive` are still unstable the impls should remain unstable. * The `From` impls for atomic integers were added in #45610 but most atomic integers are still unstable. * The `shared_from_slice2` impls were added in #45990 but they won't be stable until 1.24.0. * The `Mutex` and `RwLock` impls were added in #46082 but won't be stable until 1.24.0.
2018-01-01handle overflow/underflow in index offsetsManish Goregaokar-10/+15
2017-12-27Correct a few stability attributesOliver Middleton-2/+6
2017-12-18Add memchr search support for multibyte charactersManish Goregaokar-48/+102
2017-12-16Fill in reverse searcher impl for charManish Goregaokar-6/+50
2017-12-13Fill in forward searcher impl for charManish Goregaokar-13/+65
2017-12-13Move CharSearcher to its own section in the fileManish Goregaokar-83/+84
2017-12-13Split out char searcher from MultiCharSearcherManish Goregaokar-29/+58
2017-12-13Remove the unused ascii_only field in CharEqSearcherManish Goregaokar-16/+0
2017-12-09Use Try syntax for Option in place of macros or matchMatt Brubeck-5/+4
2017-11-13Add missing links in FromStr docsGuillaume Gomez-2/+5
2017-10-02Inline eq_slice into str::eqleonardo.yvens-12/+1
It's the only use of the function.
2017-09-29Auto merge of #44174 - jimmycuadra:try-from-infallible, r=sfacklerbors-5/+2
Add blanket TryFrom impl when From is implemented. Adds `impl<T, U> TryFrom<T> for U where U: From<T>`. Removes `impl<'a, T> TryFrom<&'a str> for T where T: FromStr` (originally added in #40281) due to overlapping impls caused by the new blanket impl. This removal is to be discussed further on the tracking issue for TryFrom. Refs #33417. /cc @sfackler, @scottmcm (thank you for the help!), and @aturon
2017-09-23TrustedRandomAccess specialisation for Cloned.Clar Charr-1/+13
This verifies that TrustedRandomAccess has no side effects when the iterator item implements Copy. This also implements TrustedLen and TrustedRandomAccess for str::Bytes.
2017-09-23Rollup merge of #44658 - leodasvacas:remove-str-eq-lang-item, r=arielb1Corey Farwell-3/+0
Remove str_eq lang item It's not really a lang item. Also remove outdated note. The reference uses this as an example so it has to be updated.
2017-09-18Rollup merge of #44657 - Ixrec:patch-1, r=eddybAlex Crichton-4/+4
Replace str's transmute() calls with pointer casts After the following conversation in #rust-lang: ``` [14:43:50] <Ixrec> TIL the implementation of from_utf_unchecked is literally just "mem::transmute(x)" [14:43:59] <Ixrec> no wonder people keep saying transmute is overpowered [15:15:30] <eddyb> Ixrec: it should be a pointer cast lol [15:15:46] <eddyb> unless it doesn't let you [16:50:34] <Ixrec> https://play.rust-lang.org/?gist=d1e6b629ad9ec1baf64ce261c63845e6&version=stable seems like it does let me [16:52:35] <eddyb> Ixrec: yeah that's the preferred impl [16:52:46] <eddyb> Ixrec: it just wasn't in 1.0 [16:52:50] <eddyb> IIRC [16:53:00] <eddyb> (something something fat pointers) ``` Since I already wrote half of the preferred impls in the playground, might as well make an actual PR.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 04:06:46 +0000