summary refs log tree commit diff
path: root/src/libcollections/vec.rs
AgeCommit message (Collapse)AuthorLines
2017-04-20Auto merge of #41191 - seanmonstar:spec-extend-vec-intoiter, r=alexcrichtonbors-8/+19
specialize Extend for Vec with IntoIter Before, `vec.extend(&other_vec)` was quite a bit faster than `vec.extend(other_vec)`. This allows extending by consuming a vec to use the same code as extending from a slice.
2017-04-19specialize Extend for Vec with IntoIterSean McArthur-8/+19
2017-04-15Specialize Vec::from_elem for other numeric typesMatt Brubeck-0/+37
2017-04-15Specialize Vec::from_elem<u8> to use calloc or memsetMatt Brubeck-3/+32
Fixes #38723.
2017-04-13Auto merge of #41009 - scottmcm:toowned-clone-into, r=alexcrichtonbors-10/+1
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.)
2017-04-12Add ToOwned::clone_into (unstable as toowned_clone_into)Scott McMurray-10/+1
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.
2017-04-06Fix Markdown issues in the docsOliver Middleton-1/+1
* Since the switch to pulldown-cmark reference links need a blank line before the URLs. * Reference link references are not case sensitive. * Doc comments need to be indented uniformly otherwise rustdoc gets confused.
2017-04-05Rollup merge of #40943 - Amanieu:offset_to, r=alexcrichtonAriel Ben-Yehuda-8/+4
Add ptr::offset_to This PR adds a method to calculate the signed distance (in number of elements) between two pointers. The resulting value can then be passed to `offset` to get one pointer from the other. This is similar to pointer subtraction in C/C++. There are 2 special cases: - If the distance is not a multiple of the element size then the result is rounded towards zero. (in C/C++ this is UB) - ZST return `None`, while normal types return `Some(isize)`. This forces the user to handle the ZST case in unsafe code. (C/C++ doesn't have ZSTs)
2017-04-05Rollup merge of #40909 - nagisa:fix-vec-placement, r=alexcrichtonAriel Ben-Yehuda-23/+23
Allow using Vec::<T>::place_back for T: !Clone The place_back was likely put into block with `T: Clone` bound by mistake.
2017-04-03Removed trailing whitespace on line 682mandeep-1/+1
2017-04-03Refactored swap_remove doc comment upon discussing with BurntSushi and ↵mandeep-2/+3
steveklabnik
2017-04-03Add ptr::offset_toAmanieu d'Antras-8/+4
2017-04-02Fixed typo in doc comments for swap_removemandeep-1/+1
2017-03-29Allow using Vec::<T>::place_back for T: !CloneSimonas Kazlauskas-23/+23
The place_back was likely put into block with `T: Clone` bound by mistake.
2017-03-22Specialize Vec::from_iter for vec::IntoIterSteven Fackler-4/+25
It's fairly common to expose an API which takes an `IntoIterator` and immediately collects that into a vector. It's also common to buffer a bunch of items into a vector and then pass that into one of these APIs. If the iterator hasn't been advanced, we can make this `from_iter` simply reassemble the original `Vec` with no actual iteration or reallocation.
2017-03-17Stabilize rc_raw feature, closes #37197Aaron Turon-2/+2
2017-03-17Rollup merge of #40536 - kevinmehall:dedup_docs_for_dedup_by, r=steveklabnikCorey Farwell-1/+5
Fix documentation for Vec::dedup_by. The previous docstring was copied from dedup_by_key.
2017-03-17Rollup merge of #40456 - frewsxcv:frewsxcv-docs-function-parens, ↵Corey Farwell-21/+21
r=GuillaumeGomez Remove function invokation parens from documentation links. 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
2017-03-15Fix documentation for Vec::dedup_by.Kevin Mehall-1/+5
The previous docstring was copied from dedup_by_key.
2017-03-13Remove function invokation parens from documentation links.Corey Farwell-21/+21
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
2017-03-10Add From<Box<..>> implementations.Clar Charr-0/+16
2017-03-07Added remove_from to vec.rsmadseagames-0/+21
2017-02-26Auto merge of #39738 - keeperofdakeys:vec-docs, r=GuillaumeGomezbors-0/+6
Add notes about capacity effects to Vec::truncate() Add notes about the effects of Vec::truncate() and Vec::clear() on the capacity of a vector.
2017-02-16Additional docs for Vec, String, and slice trait implsMatt Brubeck-0/+2
2017-02-14Add notes about capacity effects to Vec::truncate()Josh-0/+6
2017-02-13typo fixking6cong-1/+1
2017-02-09Explicitly mention that `Vec::reserve` is based on len not capacitySean Griffin-3/+6
I spent a good chunk of time tracking down a buffer overrun bug that resulted from me mistakenly thinking that `reserve` was based on the current capacity not the current length. It would be helpful if this were called out explicitly in the docs.
2017-02-07Auto merge of #39002 - GuillaumeGomez:debug_libcollections, r=aturonbors-0/+10
Add Debug implementations for libcollection structs Part of #31869.
2017-02-05Replace PlaceBack Debug implementation with deriveGuillaume Gomez-11/+3
2017-02-02std: Fix IntoIter::as_mut_slice's signatureAlex Crichton-1/+1
This was intended to require `&mut self`, not `&self`, otherwise it's unsound! Closes #39465
2017-01-25std: Stabilize APIs for the 1.16.0 releaseAlex Crichton-5/+2
This commit applies the stabilization/deprecations of the 1.16.0 release, as tracked by the rust-lang/rust issue tracker and the final-comment-period tag. The following APIs were stabilized: * `VecDeque::truncate` * `VecDeque::resize` * `String::insert_str` * `Duration::checked_{add,sub,div,mul}` * `str::replacen` * `SocketAddr::is_ipv{4,6}` * `IpAddr::is_ipv{4,6}` * `str::repeat` * `Vec::dedup_by` * `Vec::dedup_by_key` * `Result::unwrap_or_default` * `<*const T>::wrapping_offset` * `<*mut T>::wrapping_offset` * `CommandExt::creation_flags` (on Windows) * `File::set_permissions` * `String::split_off` The following APIs were deprecated * `EnumSet` - replaced with other ecosystem abstractions, long since unstable Closes #27788 Closes #35553 Closes #35774 Closes #36436 Closes #36949 Closes #37079 Closes #37087 Closes #37516 Closes #37827 Closes #37916 Closes #37966 Closes #38080
2017-01-20Remove Debug implementations specializationGuillaume Gomez-14/+0
2017-01-20Add Debug implementations for libcollection structsGuillaume Gomez-0/+32
2017-01-17Clarify when range is removed by drainStephen E. Baker-2/+2
Based on a discussion on #rust-beginners the existing note for drain is confusing. This new wording was suggested.
2017-01-14have RangeArgument return a Bound<&T> from each of its methodsdjzin-2/+11
2017-01-10Rollup merge of #38874 - derekdreery:patch-1, r=steveklabnikSeo Sanghyeon-1/+2
Update vec.rs Add a warning not to convert char* from c to Vec<u8> (I thought you could until I asked on irc). Reasoning is that it will help people avoid an error that could cause crashes and undefined behaviour. Only drawback is that it could confuse someone not familiar with C, but beginners are unlikely to be using this function anyway.
2017-01-10Rollup merge of #38664 - apasel422:may-dangle, r=pnkfelixSeo Sanghyeon-4/+2
Replace uses of `#[unsafe_destructor_blind_to_params]` with `#[may_dangle]` CC #34761 r? @pnkfelix
2017-01-06Update vec.rsderekdreery-1/+1
Changed language to stress char is the C meaning (u8) not unicode.
2017-01-06Update vec.rsderekdreery-1/+2
Add a warning not to convert char* from c to Vec<u8> (I thought you could until I asked on irc)
2016-12-28Replace uses of `#[unsafe_destructor_blind_to_params]` with `#[may_dangle]`Andrew Paseltiner-4/+2
CC #34761
2016-12-23Implement placement-in protocol for `Vec`Andrew Paseltiner-1/+73
2016-12-15Stabilize std::vec::IntoIter::{as_slice, as_mut_slice}Aaron Turon-4/+2
2016-12-06vec: More specialization for Extend<&T> for vecUlrik Sverdrup-6/+33
Specialize to use copy_from_slice when extending a Vec with &[T] where T: Copy.
2016-11-23core, collections: Implement better .is_empty() for slice and vec iteratorsUlrik Sverdrup-2/+10
These iterators can use a pointer comparison instead of computing the length.
2016-11-13vec: Use less code bloat specialized Vec::from_iterUlrik Sverdrup-20/+31
Vec::from_iter's general case allocates the vector up front; this is redundant for the TrustedLen case, and can then be avoided to reduce the size of the code.
2016-11-13Restore Vec::from_iter() specializationUlrik Sverdrup-1/+1
Since I said "no intentional functional change" in the previous commit, I guess it was inevitable there were unintentional changes. Not functional, but optimization-wise. This restores the extend specialization's use in Vec::from_iter.
2016-11-11vec: Write the .extend() specialization in cleaner styleUlrik Sverdrup-30/+41
As far as possible, use regular `default fn` specialization in favour of ad-hoc conditionals.
2016-11-04Auto merge of #37306 - bluss:trusted-len, r=alexcrichtonbors-57/+43
Add Iterator trait TrustedLen to enable better FromIterator / Extend This trait attempts to improve FromIterator / Extend code by enabling it to trust the iterator to produce an exact number of elements, which means that reallocation needs to happen only once and is moved out of the loop. `TrustedLen` differs from `ExactSizeIterator` in that it attempts to include _more_ iterators by allowing for the case that the iterator's len does not fit in `usize`. Consumers must check for this case (for example they could panic, since they can't allocate a collection of that size). For example, chain can be TrustedLen and all numerical ranges can be TrustedLen. All they need to do is to report an exact size if it fits in `usize`, and `None` as the upper bound otherwise. The trait describes its contract like this: ``` An iterator that reports an accurate length using size_hint. The iterator reports a size hint where it is either exact (lower bound is equal to upper bound), or the upper bound is `None`. The upper bound must only be `None` if the actual iterator length is larger than `usize::MAX`. The iterator must produce exactly the number of elements it reported. This trait must only be implemented when the contract is upheld. Consumers of this trait must inspect `.size_hint()`’s upper bound. ``` Fixes #37232
2016-11-04Link the tracking issue for TrustedLenUlrik Sverdrup-1/+1
2016-10-31Changed most vec! invocations to use square bracesiirelu-3/+3
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-08 04:10:04 +0000