summary refs log tree commit diff
path: root/src/libcore/slice
AgeCommit message (Collapse)AuthorLines
2019-10-25Fix slice::as_ptr_range doctest.Mara Bos-7/+10
2019-10-25Explain why pointer::add in slice::as_ptr_range is safe.Mara Bos-0/+18
2019-10-25Add slice_ptr_range tracking issue number.Mara Bos-2/+2
2019-10-25Add [T]::as_ptr_range() and [T]::as_mut_ptr_range().Mara Bos-1/+60
See https://github.com/rust-lang/rfcs/pull/2791 for motivation.
2019-10-04Allow unused attributes to avoid incremental bugMark Rousskov-0/+1
2019-09-30Auto merge of #64600 - scottmcm:no-slice-tryfold-unroll, r=blussbors-68/+1
Remove manual unrolling from slice::Iter(Mut)::try_fold While this definitely helps sometimes (particularly for trivial closures), it's also a pessimization sometimes, so it's better to leave this to (hypothetical) future LLVM improvements instead of forcing this on everyone. I think it's better for the advice to be that sometimes you need to unroll manually than you sometimes need to not-unroll manually (like #64545). --- For context see https://github.com/rust-lang/rust/pull/64572#issuecomment-532961046
2019-09-25Snap cfgs to new betaMark Rousskov-3/+1
2019-09-24Stabilize `str::len`, `[T]::len`, `is_empty` and `str::as_bytes` as const fnOliver Scherer-2/+4
2019-09-23Just delete the overrides now that they match the default implementationsScott McMurray-62/+1
2019-09-21Remove manual unrolling from slice::Iter(Mut)::try_foldScott McMurray-13/+7
While this definitely helps sometimes (particularly for trivial closures), it's also a pessimization sometimes, so it's better to leave this to (hypothetical) future LLVM improvements instead of forcing this on everyone. I think it's better for the advice to be that sometimes you need to unroll manually than you sometimes need to not-unroll manually (like #64545).
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.