| Age | Commit message (Collapse) | Author | Lines |
|
Fixes #55177
|
|
Fixes #47115
|
|
Add slice::rchunks(), rchunks_mut(), rchunks_exact() and rchunks_exact_mut()
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
----
The new iterators were motivated by a [comment](https://github.com/rust-lang/rust/issues/47115#issuecomment-424141121) by @DutchGhost.
~~~This currently includes the commits from https://github.com/rust-lang/rust/pull/54537 to not have to rename things twice or have merge conflicts. I'll force-push a new version of the branch ones those are in master.~~~
Also the stabilization tracking issue is just some number right now. I'll create the corresponding issue once this is reviewed and otherwise mergeable.
cc @DutchGhost
|
|
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
See #55177 for the tracking issue
|
|
Simplify implementation of align_offset slightly
|
|
Clarify docs for when binary_search has many matches.
Fixes https://github.com/rust-lang/rust/issues/51817.
|
|
Fixes https://github.com/rust-lang/rust/issues/51817.
|
|
Use impl_header_lifetime_elision in libcore
The feature is approved for stabilization, so let's use it to remove about 300 `'a`s.
Tracking issue for the feature: https://github.com/rust-lang/rust/issues/15872
|
|
Document that slices cannot be larger than `isize::MAX` bytes
Fixes #53676.
|
|
|
|
|
|
This reverts commit c6e3d7fa3113aaa64602507f39d4627c427742ff, reversing
changes made to 4591a245c7eec9f70d668982b1383cd2a6854af5.
|
|
|
|
Rename slice::exact_chunks() to slice::chunks_exact()
See https://github.com/rust-lang/rust/issues/47115#issuecomment-403090815
and https://github.com/rust-lang/rust/issues/47115#issuecomment-424053547
|
|
|
|
See https://github.com/rust-lang/rust/issues/47115#issuecomment-403090815
and https://github.com/rust-lang/rust/issues/47115#issuecomment-424053547
|
|
|
|
|
|
|
|
Simplify slice's first(_mut) and last(_mut) with get
This change makes these functions easier to read and interpret. I haven't detected any difference in performance locally.
r? @Mark-Simulacrum
|
|
|
|
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).
|
|
|
|
|