| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Add [[T]] -> [T] examples to SliceConcatExt docs
None
|
|
Add an in-place rotate method for slices to libcore
A helpful primitive for moving chunks of data around inside a slice.
For example, if you have a range selected and are drag-and-dropping it somewhere else (Example from [Sean Parent's talk](https://youtu.be/qH6sSOr-yk8?t=560)).
(If this should be an RFC instead of a PR, please let me know.)
Edit: changed example
|
|
|
|
See #39911
|
|
The documentation for this method appears on multiple different pages,
which causes the relative links to not always work.
|
|
`Vec::into_boxed_slice` and `[T]::into_vec` are inverses, so it makes sense
to mention the other in their respective documentation for visibility.
`Vec::into_boxed_slice` already mentions `[T]::into_vec`, but not the other
way around until now.
|
|
|
|
|
|
|
|
Batch-insert is better done with Vec::splice
|
|
A helpful primitive for moving chunks of data around inside a slice.
In particular, adding elements to the end of a Vec then moving them
somewhere else, as a way to do efficient multiple-insert. (There's
drain for efficient block-remove, but no easy way to block-insert.)
Talk with another example: <https://youtu.be/qH6sSOr-yk8?t=560>
|
|
|
|
|
|
Add a resource-reusing method to `ToOwned`
`ToOwned::to_owned` generalizes `Clone::clone`, but `ToOwned` doesn't have an equivalent to `Clone::clone_from`. This PR adds such a method as `clone_into` under a new unstable feature `toowned_clone_into`.
Analogous to `clone_from`, this has the obvious default implementation in terms of `to_owned`. I've updated the `libcollections` impls: for `T:Clone` it uses `clone_from`, for `[T]` I moved the code from `Vec::clone_from` and implemented that in terms of this, and for `str` it's a predictable implementation in terms of `[u8]`.
Used it in `Cow::clone_from` to reuse resources when both are `Cow::Owned`, and added a test that `Cow<str>` thus keeps capacity in `clone_from` in that situation.
The obvious question: is this the right place for the method?
- It's here so it lives next to `to_owned`, making the default implementation reasonable, and avoiding another trait. But allowing method syntax forces a name like `clone_into`, rather than something more consistent like `owned_from`.
- Another trait would allow `owned_from` and could support multiple owning types per borrow type. But it'd be another single-method trait that generalizes `Clone`, and I don't know how to give it a default impl in terms of `ToOwned::to_owned`, since a blanket would mean overlapping impls problems.
I did it this way as it's simpler and many of the `Borrow`s/`AsRef`s don't make sense with `owned_from` anyway (`[T;1]:Borrow<[T]>`, `Arc<T>:Borrow<T>`, `String:AsRef<OsStr>`...). I'd be happy to re-do it the other way, though, if someone has a good solution for the default handling.
(I can also update with `CStr`, `OsStr`, and `Path` once a direction is decided.)
|
|
to_owned generalizes clone; this generalizes clone_from. Use to_owned to
give it a default impl. Customize the impl for [T], str, and T:Clone.
Use it in Cow::clone_from to reuse resources when cloning Owned into Owned.
|
|
|
|
|
|
Checked slicing for strings
cc https://github.com/rust-lang/rust/issues/39932
|
|
|
|
What is this magic‽
|
|
|
|
|
|
|
|
|
|
|
|
Add mention of None as possible return. Closes #40435.
This commit adds a small mention to some methods that None is returned when the slice is empty.
|
|
minor wording tweak to slice::{as_ptr, as_mut_ptr}
Per #37334, the slice-as-pointer methods mentioned that "modifying the slice may cause its buffer to be reallocated", when in fact modifying the *slice* itself would cause no such change. (It is a borrow, after all!) This is a tweak to the wording of that line to stress it's the *collection* that could cause the buffer to be reallocated.
r? @steveklabnik
|
|
|
|
|
|
This was never established as a convention we should follow in the 'More
API Documentation Conventions' RFC:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md
|
|
First, get rid of some bound checks.
Second, instead of comparing by ternary `compare` function, use a binary
function testing whether an element is less than some other element.
This apparently makes it easier for the compiler to reason about the
code.
Benchmark:
```
name before ns/iter after ns/iter diff ns/iter diff %
slice::bench::sort_large_ascending 8,969 (8919 MB/s) 7,410 (10796 MB/s) -1,559 -17.38%
slice::bench::sort_large_big_ascending 355,640 (3599 MB/s) 359,137 (3564 MB/s) 3,497 0.98%
slice::bench::sort_large_big_descending 427,112 (2996 MB/s) 424,721 (3013 MB/s) -2,391 -0.56%
slice::bench::sort_large_big_random 2,207,799 (579 MB/s) 2,138,804 (598 MB/s) -68,995 -3.13%
slice::bench::sort_large_descending 13,694 (5841 MB/s) 13,514 (5919 MB/s) -180 -1.31%
slice::bench::sort_large_mostly_ascending 239,697 (333 MB/s) 203,542 (393 MB/s) -36,155 -15.08%
slice::bench::sort_large_mostly_descending 270,102 (296 MB/s) 234,263 (341 MB/s) -35,839 -13.27%
slice::bench::sort_large_random 513,406 (155 MB/s) 470,084 (170 MB/s) -43,322 -8.44%
slice::bench::sort_large_random_expensive 23,650,321 (3 MB/s) 23,675,098 (3 MB/s) 24,777 0.10%
slice::bench::sort_medium_ascending 143 (5594 MB/s) 132 (6060 MB/s) -11 -7.69%
slice::bench::sort_medium_descending 197 (4060 MB/s) 188 (4255 MB/s) -9 -4.57%
slice::bench::sort_medium_random 3,358 (238 MB/s) 3,271 (244 MB/s) -87 -2.59%
slice::bench::sort_small_ascending 32 (2500 MB/s) 32 (2500 MB/s) 0 0.00%
slice::bench::sort_small_big_ascending 97 (13195 MB/s) 97 (13195 MB/s) 0 0.00%
slice::bench::sort_small_big_descending 247 (5182 MB/s) 249 (5140 MB/s) 2 0.81%
slice::bench::sort_small_big_random 502 (2549 MB/s) 498 (2570 MB/s) -4 -0.80%
slice::bench::sort_small_descending 55 (1454 MB/s) 61 (1311 MB/s) 6 10.91%
slice::bench::sort_small_random 358 (223 MB/s) 356 (224 MB/s) -2 -0.56%
```
|
|
For every method, the first sentence should consisely explain what it does,
not how. This sentence usually starts with a verb.
It's really weird for `sort` to be explained in terms of another function,
namely `sort_by`. There's no need for that because it's obvious how `sort`
sorts elements: there is `T: Ord`.
If `sort_by_key` does not have to explicitly state how it's implemented,
then `sort` doesn't either.
|
|
|
|
|
|
|
|
Fixes #38524
|
|
A few improvements to the slice docs.
* Simplify `Option::iter_mut` doc example.
* Document 'empty' corner-cases for `slice::{starts_with, ends_with}`.
* Indicate 'true' as code-like.
|
|
* Simplify `Option::iter_mut` doc example.
* Document 'empty' corner-cases for `slice::{starts_with, ends_with}`.
* Indicate 'true' as code-like.
|
|
for the new SliceIndex trait. Also made the docs of the unchecked
versions a bit clearer; they return a reference, not an "unsafe
pointer".
|
|
|
|
There was an off-by-one error discovered by @tbelaire.
So, the two invariants we are enforcing are:
1. Run lengths are decreasing.
2. Sum of lengths of any two adjacent runs is less than the length of
their predecessor.
This commit changes the comment to be clearer and have correct bounds on `i`.
|
|
Since merge_sort is generic and collapse isn't, that means calls to
collapse won't be inlined. inlined. Therefore, we must stick an
`#[inline]` above `fn collapse`.
|
|
This is a complete rewrite of the standard sort algorithm. The new algorithm
is a simplified variant of TimSort. In summary, the changes are:
* Improved performance, especially on partially sorted inputs.
* Performs less comparisons on both random and partially sorted inputs.
* Decreased the size of temporary memory: the new sort allocates 4x less.
|
|
|
|
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
|
|
|
|
Fix some typos and improve doc comments style
r? @steveklabnik
|
|
|
|
|
