| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Update docs for str::as_bytes_mut.
* Add "Safety" section describing UTF-8 invariant.
* Remove mention of `from_utf8_mut`. It is not necessary to call
a function to convert the byte slice back to a string slice. The
original string becomes accessible again after the byte slice is
no longer used (as shown in the example code).
|
|
* Add "Safety" section describing UTF-8 invariant.
* Remove mention of `from_utf8_mut`. It is not necessary to call
a function to convert the byte slice back to a string slice. The
original string becomes accessible again after the byte slice is
no longer used (as shown in the example code).
|
|
Clarify the description for rfind
Changes the wording in rfind description to be clearer and the example code to illustrate the difference between
find and rfind
|
|
add (unchecked) indexing methods to raw (and NonNull) slices
This complements the existing (unstable) `len` method. Unfortunately, for non-null slices, we cannot call this method `as_ptr` as that overlaps with the existing method of the same name.
If this looks reasonable to accept, I propose to reuse the https://github.com/rust-lang/rust/issues/71146 tracking issue and rename the feature get to `slice_ptr_methods` or so.
Cc @SimonSapin
Fixes https://github.com/rust-lang/rust/issues/60639
|
|
Changes the example code to illustrate the difference between
find and rfind
|
|
|
|
|
|
And final part!!!
|
|
|
|
|
|
Clarify the behaviour of Pattern when used with methods like str::contains
Fixes #45507.
I used the previous work by @Emerentius (thanks !), added a paragraph and checked the links (they work for me but I'm not against someone else checking them too).
|
|
|
|
|
|
Fix is_char_boundary documentation
Given the "start _and/or end_" wording in the original, the way I understood it was that the `str::is_char_boundary` method would also return `true` for the last byte in a UTF-8 code point sequence. (Which would have meant that for a string consisting of nothing but 1 and 2 byte UTF-8 code point sequences, it would return nothing but `true`.)
In practice the method returns `true` only for the starting byte of each sequence and the end of the string: [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e9f5fc4d6bf2f1bf57a75f3c9a180770)
I was also somewhat tempted to remove the _The start and end of the string are considered to be boundaries_, since that's implied by the first sentence, but I decided to avoid bikeshedding over it and left it as it was since it's not wrong in relation to how the method behaves.
|
|
|
|
|
|
|
|
Use assoc int consts3
Define module level int consts with associated constants instead of `min_value()` and `max_value()`. So the code become consistent with what the docs recommend etc. Seems natural.
Also remove the last usages of the int module constants from this repo (except src/test/ directory which I have still not really done anything in). Some places were missed in the previous PRs because the code uses `crate::<IntTy>` to reach the constants.
This is a continuation of #70857
r? @dtolnay
|
|
|
|
|
|
|
|
|
|
Fix incorrect documentation for `str::{split_at, split_at_mut}`
The documentation for each method currently states:
> Panics if `mid` is not on a UTF-8 code point boundary, or if it is beyond the last code point of the string slice.
However, this is not consistent with the real behavior, or that of the corresponding methods for `[T]` slices. A comment inside each of the `str` methods states:
> is_char_boundary checks that the index is in [0, .len()]
That is what I would expect the behavior to be, and in fact this seems to be the real behavior. For example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8e03dcc209d4dd176df2297523f9fee1)):
```rust
fn main() {
// Prints ("abc", "") and doesn't panic
println!("{:?}", "abc".split_at(3));
}
```
In this case, I would interpret "the last code point of the string slice" to mean the byte at index 2 in UTF-8. However, it is possible to pass an index of 3, which is definitely "beyond the last code point of the string slice".
I think that this is much clearer, but feel free to bikeshed.
|
|
|
|
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.
|
|
|
|
negatives fixed recently)
|
|
|
|
|
|
Prior to this commit, `str` documented that `get_unchecked` had
the precondition that "`begin` must come before `end`". This would appear
to prohibit empty slices (i.e. begin == end).
In practice, get_unchecked is called often with empty slices. Let's relax
the precondition so as to allow them.
|
|
Implement split_inclusive for slice and str
# Overview
* Implement `split_inclusive` for `slice` and `str` and `split_inclusive_mut` for `slice`
* `split_inclusive` is a substring/subslice splitting iterator that includes the matched part in the iterated substrings as a terminator.
* EDIT: The behaviour has now changed, as per @KodrAus 's input, to the same semantics with the `split_terminator` function. I updated the examples below.
* Two examples below:
```Rust
let data = "\nMäry häd ä little lämb\nLittle lämb\n";
let split: Vec<&str> = data.split_inclusive('\n').collect();
assert_eq!(split, ["\n", "Märy häd ä little lämb\n", "Little lämb\n"]);
```
```Rust
let uppercase_separated = "SheePSharKTurtlECaT";
let mut first_char = true;
let split: Vec<&str> = uppercase_separated.split_inclusive(|c: char| {
let split = !first_char && c.is_uppercase();
first_char = split;
split
}).collect();
assert_eq!(split, ["SheeP", "SharK", "TurtlE", "CaT"]);
```
# Justification for the API
* I was surprised to find that stdlib currently only has splitting iterators that leave out the matched part. In my experience, wanting to leave a substring terminator as a part of the substring is a pretty common usecase.
* This API is strictly more expressive than the standard `split` API: it's easy to get the behaviour of `split` by mapping a subslicing operation that drops the terminator. On the other hand it's impossible to derive this behaviour from `split` without using hacky and brittle `unsafe` code. The normal way to achieve this functionality would be implementing the iterator yourself.
* Especially when dealing with mutable slices, the only way currently is to use `split_at_mut`. This API provides an ergonomic alternative that plays to the strengths of the iterating capabilities of Rust. (Using `split_at_mut` iteratively used to be a real pain before NLL, fortunately the situation is a bit better now.)
# Discussion items
* <s>Does it make sense to mimic `split_terminator` in that the final empty slice would be left off in case of the string/slice ending with a terminator? It might do, as this use case is naturally geared towards considering the matching part as a terminator instead of a separator.</s>
* EDIT: The behaviour was changed to mimic `split_terminator`.
* Does it make sense to have `split_inclusive_mut` for `&mut str`?
|
|
Miscellaneous inlining improvements
These commits inline some hot functions that aren't currently inlined, for some speed wins.
r? @Centril
|
|
It only has two call sites, and the one within `from_utf8` is hot within
rustc itself.
|
|
Updating str.chars docs to mention crates.io.
This might spare someone else a little time searching the stdlib for unicode/grapheme support.
|
|
reverse iteration.
|
|
includes the matched part in the iterated substrings as a terminator.
|
|
|
|
This might spare someone else a little time searching the stdlib for unicode/grapheme support.
|
|
|
|
|
|
|
|
Co-Authored-By: Ralf Jung <post@ralfj.de>
|
|
|
|
|
|
|
|
Require issue = "none" over issue = "0" in unstable attributes
These changes make the use of `issue = "none"` required in unstable attributes throughout the compiler.
Notes:
- #66299 is now in beta so `issue = "none"` is accepted.
- The `tidy` tool now fails on `issue = "0"`.
- Tests that used `issue = "0"` were changed to use `issue = "none"`, except for _one_ that asserts `issue = "0"` can still be used.
- The compiler still allows `issue = "0"` because some submodules require it, this could be disallowed once these are updated.
Resolves #41260
r? @varkor
|
|
|
