| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Deny unsafe ops in unsafe fns in libcore
After `liballoc`, It's time for `libcore` :D
I planned to do this bit by bit to avoid having a big chunk of diffs, so to make reviews easier, and to make the unsafe blocks narrower and take the time to document them properly.
r? @nikomatsakis cc @RalfJung
|
|
|
|
And final part!!!
|
|
|
|
|
|
Add partition_point
Add partition_point in C++.
Although existing binary_search in rust does not suitable when the slice has multiple hits,
this function returns exact point of partition.
The definition of this function is very clear and able to accept general matter, therefore you can easily get index which you want like lower/upper_bound.
https://github.com/rust-lang/rfcs/issues/2184
|
|
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
|
|
|
|
|
|
|
|
Co-authored-by: Lukas Kalbertodt <lukas.kalbertodt@gmail.com>
|
|
|
|
|
|
A way forward for pointer equality in const eval
r? @varkor on the first commit and @RalfJung on the second commit
cc #53020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These are simply indexing safety.
|
|
We already implicitly (or explicitly??) do the bound checking for the indexing.
|
|
This is just the reverse of shift_head.
|
|
|
|
Migrate to numeric associated consts
The deprecation PR is #72885
cc #68490
cc rust-lang/rfcs#2700
|
|
|
|
|
|
Doc comments of 'copy_from_slice' say that people should use 'clone_from_slice'
when 'src' doesn't implement 'Copy'. However, 'src' is a reference and
it always implements 'Copy'. The term 'src' should be fixed to 'T' in
the doc comments.
Thank you for reviewing this PR :)
|
|
|
|
|
|
This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.
Providing that very pattern as a counter-example could help mitigate that.
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
The default implementations of several `Iterator` methods use `fold` or
`try_fold`, which works, but is overkill for slices and bloats the
amount of LLVM IR generated and consequently hurts compile times.
This commit adds the simple, obvious implementations for `for_each`,
`all`, `any`, `find`, `find_map`, and simplifies the existing
implementations for `position` and `rposition`. These changes reduce
compile times significantly on some benchmarks.
|
|
|
|
|
|
|
|
|
|
|
|
Add slice::fill
Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function.
## Usage
```rust
let mut buf = vec![0; 10];
buf.fill(1);
assert_eq!(buf, vec![1; 10]);
```
## Performance
When compiling in release mode, for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile.
## Why now?
Conversations about adding `slice::fill` are not new. In fact, https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details, and it's not seen much forward motion since.
In ["The Hunt for the Fastest Zero"](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc, comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests, the author notes the following:
> That the optimization fails, perhaps unexpectedly, in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms, at least where performance matters, for example by replacing std::fill with memset? I don’t think so.
Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values, so it either needs to be optimized at the MIR layer, or more likely rely on LLVM's optimizer.
By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec<u8>` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that, it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples.
## References
- [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/)
- [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html)
- [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067)
- [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill)
- [ASM output on Godbolt](https://godbolt.org/z/5-XU66)
|
|
|
|
|
|
|
|
For all of the methods that pick off the first or last element, we can
use subslice patterns to implement them directly, rather than relying on
deeper indexing function calls. At a minimum, this means the generated
code will rely less on inlining for performance, but in some cases it
also optimizes better.
|
|
fix aliasing violation in align_to_mut
Fixes https://github.com/rust-lang/rust/issues/68549
I decided to add the testcase here to make it all one PR, but if you prefer I can also add that test case in the Miri repo instead.
|
|
|
|
|
|
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`?
|
|
reverse iteration.
|
