| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This is a safe wrapper around ptr::copy, for regions within a single
slice. Previously, safe in-place copying was only available as a side
effect of Vec::drain.
|
|
|
|
|
|
stabilize slice_align_to
This is very hard to implement correctly, and leads to [serious bugs](https://github.com/llogiq/bytecount/pull/42) when done incorrectly. Moreover, this is needed to be able to run code that opportunistically exploits alignment on miri. So code using `align_to`/`align_to_mut` gets the benefit of a well-tested implementation *and* of being able to run in miri to test for (some kinds of) UB.
This PR also clarifies the guarantee wrt. the middle part being as long as possible. Should the docs say under which circumstances the middle part could be shorter? Currently, that can only happen when running in miri.
|
|
|
|
|
|
Copy the documentation over to `slice::from_raw_parts_mut`.
|
|
Fixes #53676.
|
|
|
|
|
|
|
|
Replace usages of ptr::offset with ptr::{add,sub}.
Rust provides these helper methods – so let's use them!
|
|
Fix typos found by codespell.
|
|
|
|
|
|
debug_assert to ensure that from_raw_parts is only used properly aligned
This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by https://github.com/rust-lang/rust/issues/42789 *if* there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently [fail in the rg testsuite](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). So maybe it is worth it, after all.
I have seen the attribute `#[rustc_inherit_overflow_checks]` in some places, does that make it so that the *caller's* debug status is relevant? Is there a similar attribute for `debug_assert!`? That could even subsume `rustc_inherit_overflow_checks`: Something like `rustc_inherit_debug_flag` could affect *all* places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason *not* to handle the debug flag that way? I guess currently we apply debug flags like `cfg` so this is dropped early during the MIR pipeline?
EDIT: I learned from @eddyb that because of how `debug_assert!` works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^
|
|
Remove explicit returns where unnecessary
|
|
|
|
|
|
|
|
|
|
|
|
slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts
This fixes the problem that we are fabricating pointers out of thin air. I also managed to share more code between the mutable and shared iterators, while reducing the amount of macros.
I am not sure how useful it really is to add a `debug_assert!` in libcore. Everybody gets a release version of that anyway, right? Is there at least a CI job that runs the test suite with a debug version?
Fixes #42789
|
|
|
|
|
|
Also use ident, not expr, to avoid accidental side-effects
|
|
This also changes the IR for nth(), but the new IR actually looks nicer that the old
(and it is one instruction shorter).
|
|
|
|
|
|
|
|
|
|
|
|
make memrchr use align_offset
I hope I did not screw that up...
Cc @oli-obk who authored the original https://github.com/rust-lang/rust/pull/44537
Fixes #50567 (thanks @bjorn3)
|
|
|
|
|
|
|
|
Change RangeInclusive to a three-field struct.
Fix #45222.
This PR also reverts #48012 (i.e. removed the `try_fold`/`try_rfold` specialization for `RangeInclusive`) because LLVM no longer has trouble recognizing a RangeInclusive loop.
|
|
Fix #45222.
|
|
Add ExactChunks::remainder and ExactChunks::into_remainder
These allow to get the leftover items of the slice that are not being
iterated as part of the iterator due to not filling a complete chunk.
The mutable version consumes the slice because otherwise we would either
a) have to borrow the iterator instead of taking the lifetime of
the underlying slice, which is not what *any* of the other iterator
functions is doing, or
b) would allow returning multiple mutable references to the same data
The current behaviour of consuming the iterator is consistent with
IterMut::into_slice for the normal iterator.
----
This is related to https://github.com/rust-lang/rust/issues/47115#issuecomment-392685177 and the following comments.
While there the discussion was first about a way to get the "tail" of the iterator (everything from the slice that is still not iterated yet), this gives kind of unintuitive behaviour and is inconsistent with how the other slice iterators work.
Unintuitive because the `next_back` would have no effect on the tail (or otherwise the tail could not include the remainder items), inconsistent because a) generally the idea of the slice iterators seems to be to only ever return items that were not iterated yet (and don't provide a way to access the same item twice) and b) we would return a "flat" `&[T]` slice but the iterator's shape is `&[[T]]` instead, c) the mutable variant would have to borrow from the iterator instead of the underlying slice (all other iterator functions borrow from the underlying slice!)
As such, I've only implemented functions to get the remainder. This also allows the implementation to be completely safe still (and around slices instead of raw pointers), while getting the tail would either be inefficient or would have to be implemented around raw pointers.
CC @kerollmops
|
|
Better docs for copy_from_slice & clone_from_slice
I copy-pasted the text from clone_from_slice to copy_from_slice :smile:
@steveklabnik feel free to suggest changes.
edit: closes #49769
|
|
|
|
|
|
Bootstrap from 1.28.0 beta
|
|
|
|
Use assert_eq! in copy_from_slice
This will print both lengths when the assertion fails instead of just saying that they're different.
Output of current stable and nightly (modulo the exact line number):
```
thread 'main' panicked at 'destination and source slices have different lengths', libcore/slice/mod.rs:1645:9
```
Output after this PR:
```
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `123`,
right: `456`: destination and source slices have different lengths', libcore/slice/mod.rs:1645:9
```
Note that I have not run the tests locally.
|
|
|
|
These were stabilized in March 2018's #47813, and are the Preferred Way
to Do It going forward (q.v. #51043).
|
|
|
|
This will print both lengths when the assertion fails instead of just saying that they're different.
|
