about summary refs log tree commit diff
path: root/src/libcore/slice
AgeCommit message (Collapse)AuthorLines
2019-08-22Apply clippy::let_and_return suggestionMateusz Mikuła-2/+1
2019-08-20Rollup merge of #63265 - JohnTitor:implement-nth-back-for-chunksexactmut, ↵Mazdak Farrokhzad-0/+16
r=scottmcm Implement `nth_back` for ChunksExactMut This is a part of #54054. r? @scottmcm
2019-08-10Use Result::unwrap_or_else instead of matchingLzu Tao-4/+1
2019-08-10Add an example to show how to insert item to a sorted vecLzu Tao-0/+14
2019-08-09Auto merge of #61937 - AaronKutch:master, r=scottmcmbors-69/+152
Improve `ptr_rotate` performance, tests, and benches The corresponding issue is #61784. I am not actually sure if miri can handle the test, but I can change the commit if necessary.
2019-08-06Improve `ptr_rotate` performance, tests, and benchmarksAaron Kutch-69/+152
2019-08-05Clarify align_to's requirements and obligationsJake Goulding-6/+8
2019-08-05Implement nth_back for ChunksExactMutYuki Okushi-0/+16
2019-08-04fix linksRalf Jung-2/+2
relative links do not work because this is included in several places
2019-08-03Apply suggestions from code reviewRalf Jung-8/+12
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-08-03clarify that unchecked indexing is UB even if the reference is never usedRalf Jung-4/+12
2019-07-28Rollup merge of #62074 - wizAmit:feature/mut_chunks_nth_back, r=scottmcmMazdak Farrokhzad-0/+19
squash of all commits for nth_back on ChunksMut wip nth_back for chunks_mut working chunksmut fixed nth_back for chunksmut Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com> r? @timvermeulen r? @scottmcm
2019-07-25Auto merge of #60340 - mgeier:cap-vs-capacity, r=alexcrichtonbors-2/+2
Rename .cap() methods to .capacity() As mentioned in #60316, there are a few `.cap()` methods, which seem out-of-place because such methods are called `.capacity()` in the rest of the code. This PR renames them to `.capacity()` but leaves `RawVec::cap()` in there for backwards compatibility. I didn't try to mark the old version as "deprecated", because I guess this would cause too much noise.
2019-07-23Rollup merge of #62656 - RalfJung:contains-no-own, r=Dylan-DPCMark Rousskov-0/+9
explain how to search in slice without owned data Cc https://github.com/rust-lang/rust/issues/62367
2019-07-19avoid uninit_array! macro where it is not neededRalf Jung-2/+2
2019-07-19use const array repeat expressions for uninit_arrayRalf Jung-2/+2
2019-07-18Rollup merge of #62728 - DutchGhost:fix-double-wording, r=jonas-schievinkMark Rousskov-3/+3
Fix repeated wording in slice documentation Changes `of the slice of the slice` to `of the slice` in the chunk- and friends documentation of slices
2019-07-16found more repeated wordingDodo-2/+2
2019-07-16fix double wordingDodo-1/+1
2019-07-15Add debug assertions to write_bytes and copy*Valentin Tolmer-3/+3
2019-07-14better commentsRalf Jung-3/+4
2019-07-13explain how to search without owned dataRalf Jung-0/+8
2019-07-11Rollup merge of #61665 - aschampion:slice-eq-ptr, r=sfacklerMazdak Farrokhzad-6/+17
core: check for pointer equality when comparing Eq slices Because `Eq` types must be reflexively equal, an equal-length slice to the same memory location must be equal. This is related to #33892 (and #32699) answering this comment from that PR: > Great! One more easy question: why does this optimization not apply in the non-BytewiseEquality implementation directly above? Because slices of non-reflexively equal types (like `f64`) are not equal even if it's the same slice. But if the types are `Eq`, we can use this same-address optimization, which this PR implements. Obviously this changes behavior if types violate the reflexivity condition of `Eq`, because their impls of `PartialEq` will no longer be called per-item, but 🤷‍♂ . It's not clear how often this optimization comes up in the real world outside of the same-`&str` case covered by #33892, so **I'm requesting a perf run** (on MacOS today, so can't run `rustc_perf` myself). I'm going ahead and making the PR on the basis of being surprised things didn't already work this way. This is my first time hacking rust itself, so as a perf sanity check I ran `./x.py bench --stage 0 src/lib{std,alloc}`, but the differences were noisy. To make the existing specialization for `BytewiseEquality` explicit, it's now a supertrait of `Eq + Copy`. `Eq` should be sufficient, but `Copy` was included for clarity.
2019-07-08Auto merge of #62473 - timvermeulen:is_sorted_by_key, r=scottmcmbors-2/+2
Only call the closure parameter of Iterator::is_sorted_by_key once per item See https://github.com/rust-lang/rust/issues/53485#issuecomment-472314004. This changes `Iterator::is_sorted_by_key` to only call the given closure once for each item, which allows us to pass the items to the closure by value instead of by reference. **Important**: `is_sorted_by_key` for slices and slice iterators is now no longer implemented in terms of the custom `slice::Iter::is_sorted_by` implementation. It's a trade-off: we could forward `slice::Iter::is_sorted_by_key` to it directly for potential SIMD benefits, but that would mean that the closure is potentially called twice for (almost) every element of the slice.
2019-07-07Only call the closure parameter of Iterator::is_sorted_by_key once per itemTim Vermeulen-2/+2
2019-06-23squash of all commits for nth_back on ChunksMut@amit.chandra-0/+19
wip nth_back for chunks_mut working chunksmut fixed nth_back for chunksmut Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
2019-06-23squash commit for nth_back on chunks exact@amit.chandra-0/+15
wip nth_back for chunks_exact working nth_back for chunks exact Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
2019-06-20Rollup merge of #60772 - timvermeulen:slice_iter_nth_back, r=scottmcmMazdak Farrokhzad-21/+55
Implement nth_back for slice::{Iter, IterMut} Part of #54054. I implemented `nth_back` as straightforwardly as I could, and then slightly changed `nth` to match `nth_back`. I believe I did so correctly, but please double-check 🙂 I also added the helper methods `zst_shrink`, `next_unchecked`, and `next_back_unchecked` to get rid of some duplicated code. These changes hopefully make this code easier to understand for new contributors like me. I noticed the `is_empty!` and `len!` macros which sole purpose seems to be inlining, according to the comment right above them, but the `is_empty` and `len` methods are already marked with `#[inline(always)]`. Does that mean we could replace these macros with method calls, without affecting anything? I'd love to get rid of them.
2019-06-19Add functions to build raw slicesOliver Scherer-16/+3
2019-06-15Help LLVM better optimize slice::Iter(Mut)::lenScott McMurray-4/+17
2019-06-13Rollup merge of #61398 - kennytm:stabilize-copy-within, r=SimonSapinMazdak Farrokhzad-4/+3
Stabilize copy_within Closes #54236.
2019-06-10core: use memcmp optimization for 128 bit integer slicesAndrew Champion-1/+1
2019-06-08core: use iterators for slice equality comparisonAndrew Champion-14/+2
2019-06-08core: check for pointer equality when comparing Eq slicesAndrew Champion-1/+24
Because Eq types must be reflexively equal, an equal-length slice to the same memory location must be equal.
2019-06-02copy_within: replace element access by pointer arithmetic to avoid UBkennytm-2/+2
This ensures we won't accidentally read *src or *dest even when count = 0.
2019-05-31Stabilize copy_withinkennytm-2/+1
2019-05-29Rollup merge of #61048 - wizAmit:feature/nth_back_chunks, r=scottmcmMazdak Farrokhzad-0/+18
Feature/nth back chunks A succinct implementation for nth_back on chunks. Thank you @timvermeulen for the guidance. r? @timvermeulen
2019-05-29Rollup merge of #60555 - timvermeulen:rchunks_nth_back, r=scottmcmMazdak Farrokhzad-0/+72
Implement nth_back for RChunks(Exact)(Mut) Part of #54054. These implementations may not be optimal because of the use of `self.len()`, but it's quite cheap and simplifies the code a lot. There's quite some duplication going on here, I wouldn't mind cleaning this up later. A good next step would probably be to add private `split_off_up_to`/`split_off_from` helper methods for slices since their behavior is commonly useful throughout the `Chunks` types. r? @scottmcm
2019-05-25Implement nth_back for slice::{Iter, IterMut}Tim Vermeulen-21/+55
2019-05-22Revert "Add implementations of last in terms of next_back on a bunch of ↵Steven Fackler-20/+0
DoubleEndedIterators." This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
2019-05-22succint implementationwizAmit-0/+18
2019-05-22wip nth_back on chunks@amit.chandra-17/+0
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
2019-05-22hopefully working nth_back on chunks@amit.chandra-8/+9
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
2019-05-22wip nth_back on chunks@amit.chandra-0/+16
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
2019-05-14Rollup merge of #60443 - RalfJung:as_ptr, r=SimonSapinMazdak Farrokhzad-0/+6
as_ptr returns a read-only pointer Add comments to `as_ptr` methods to warn that these are read-only pointers, and writing to them is UB. [It was pointed out](https://internals.rust-lang.org/t/as-ptr-vs-as-mut-ptr/9940) that `CStr` does not even have an `as_mut_ptr`. I originally was going to add one, but there is no method at all that would mutate a `CStr`. Was that a deliberate choice or should I add an `as_mut_ptr` (similar to [what I did for `str`](https://github.com/rust-lang/rust/pull/58200))?
2019-05-14Rollup merge of #60130 - khuey:efficient_last, r=sfacklerMazdak Farrokhzad-0/+20
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators. I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so. The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
2019-05-05Implement nth_back for RChunks(Exact)(Mut)Tim Vermeulen-0/+72
2019-05-02clarify wordingRalf Jung-2/+2
2019-05-01as_ptr returns a read-only pointerRalf Jung-0/+6
2019-04-27Rename .cap() methods to .capacity()Matthias Geier-2/+2
... but leave the old names in there for backwards compatibility.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 06:40:18 +0000