| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This adds a few more statements to `next`, but optimizes better in the loops (saving 2 blocks in `forward_loop`, for example)
|
|
Probably reasonable anyway since it more obviously drops provenance.
|
|
|
|
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
|
|
Since the stabilization in #127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.
I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
|
|
|
|
With all the MIR optimization changes that have happened since these were written, let's see if they still actually matter.
|
|
|
|
|
|
|
|
`assume`s
|
|
this seems to produce less IR
|
|
|
|
Currently, slice iterators over ZSTs store `end = start.wrapping_byte_add(len)`.
That's slightly convenient for `is_empty`, but kinda annoying for pretty much everything else -- see bugs like 42789, for example.
This PR instead changes it to just `end = ptr::invalid(len)` instead.
That's easier to think about (IMHO, at least) as well as easier to represent.
|
|
|
|
|
|
I noticed that `post_inc_start` and `pre_dec_end` were doing this check in different ways
https://github.com/rust-lang/rust/blob/d19b64fb54391b64ce99981577c67c93ac2a9ffa/library/core/src/slice/iter/macros.rs#L76-L93
so started making this PR, then added a few more I found since I was already making changes anyway.
|
|
|
|
A successful advance is now signalled by returning `0` and other values now represent the remaining number
of steps that couldn't be advanced as opposed to the amount of steps that have been advanced during a partial advance_by.
This simplifies adapters a bit, replacing some `match`/`if` with arithmetic. Whether this is beneficial overall depends
on whether `advance_by` is mostly used as a building-block for other iterator methods and adapters or whether
we also see uses by users where `Result` might be more useful.
|
|
|
|
This way one can `mem::take()` them out of structs or #[derive(Default)] on structs containing them.
These changes will be insta-stable.
|
|
|
|
|
|
|
|
There's a bunch of these checks because of special handing for ZSTs in various unsafe implementations of stuff.
This lets them be `T::IS_ZST` instead of `mem::size_of::<T>() == 0` every time, making them both more readable and more terse.
*Not* proposed for stabilization at this time. Would be `pub(crate)` except `alloc` wants to use it too.
(And while it doesn't matter now, if we ever get something like 85836 making it a const can help codegen be simpler.)
|
|
|
|
...replacing `.cast().wrapping_offset().cast()` & similar code.
|
|
|
|
with those of `next()` on adapters that have both.
It improves the performance of iterators using unchecked access when building in incremental mode
(due to the larger CGU count?). It might negatively affect incremental compile times for better runtime results,
but considering that the equivalent `next()` implementations also are `#[inline]` and usually are more complex this
should be ok.
```
./x.py bench library/core -i --stage 0 --test-args bench_trusted_random_access
OLD: 119,172 ns/iter
NEW: 17,714 ns/iter
```
|
|
|
|
Some things like the unwinders and system APIs are not fully conformant,
this only covers a lot of low-hanging fruit.
|
|
|
|
Co-authored-by: Ivan Tham <pickfire@riseup.net>
|
|
|
|
Co-authored-by: The8472 <git@infinite-source.de>
|
|
It's possible for method resolution to pick this method over a lower
priority stable method, causing compilation errors. Since this method
is permanently unstable, give it a name that is very unlikely to be used
in user code.
|
|
|
