| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
|
|
|
|
|
|
Improve code generated for `starts_with(<literal char>)`
This PR includes two minor improvements to the code generated when checking for string prefix/suffix.
The first commit simplifies the str/str operation, by taking advantage of the raw UTF-8 representation.
The second commit replaces the current str/char matching logic with a char->str encoding and then the previous method.
The resulting code should be equivalent in the generic case (one char is being encoded versus one char being decoded), but it becomes easy to optimize in the case of a literal char, which in most cases a developer might expect to be at least as simple as that of a literal string.
This PR should fix #41993
|
|
Add str::strip_prefix and str::strip_suffix
Introduces a counterpart for `Path::strip_prefix` on `str`.
This was also discussed in https://internals.rust-lang.org/t/pre-pr-path-strip-prefix-counterpart-in-str/11364/.
|
|
|
|
functions with a `const` modifier
|
|
|
|
This enables constant folding when matching a literal char.
Fixes #41993.
|
|
The comparison can be performed on the raw bytes, as the chars can
only match if their UTF8 encoding matches.
This avoids the `is_char_boundary` checks and translates to a straight
`u8` slice comparison which is optimized to a memcmp or inline
comparison where appropriate.
|
|
|
|
Made it the same as rmatches()
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
