about summary refs log tree commit diff
path: root/src/libstd/slice.rs
AgeCommit message (Collapse)AuthorLines
2014-05-27std: Rename strbuf operations to stringRicho Healey-8/+8
[breaking-change]
2014-05-27std: Remove String's to_ownedRicho Healey-2/+2
2014-05-23std: Move unstable::finally to std::finally. #1457Brian Anderson-1/+1
[breaking-change]
2014-05-23auto merge of #14360 : alexcrichton/rust/remove-deprecated, r=kballardbors-15/+1
These have all been deprecated for awhile now, so it's likely time to start removing them.
2014-05-22libstd: Remove `~str` from all `libstd` modules except `fmt` and `str`.Patrick Walton-8/+10
2014-05-22Remove a slew of old deprecated functionsAlex Crichton-15/+1
2014-05-21migrate from `exchange_malloc` to `allocate`Daniel Micay-3/+3
This is now only used internally by the compiler.
2014-05-20core: Stabilize the mem moduleAlex Crichton-3/+5
Excluding the functions inherited from the cast module last week (with marked stability levels), these functions received the following treatment. * size_of - this method has become #[stable] * nonzero_size_of/nonzero_size_of_val - these methods have been removed * min_align_of - this method is now #[stable] * pref_align_of - this method has been renamed without the `pref_` prefix, and it is the "default alignment" now. This decision is in line with what clang does (see url linked in comment on function). This function is now #[stable]. * init - renamed to zeroed and marked #[stable] * uninit - marked #[stable] * move_val_init - renamed to overwrite and marked #[stable] * {from,to}_{be,le}{16,32,64} - all functions marked #[stable] * swap/replace/drop - marked #[stable] * size_of_val/min_align_of_val/align_of_val - these functions are marked #[unstable], but will continue to exist in some form. Concerns have been raised about their `_val` prefix. [breaking-change]
2014-05-12register snapshotsDaniel Micay-48/+0
2014-05-11heap: replace `exchange_free` with `deallocate`Daniel Micay-4/+4
The `std::rt::heap` API is Rust's global allocator, so there's no need to have this as a separate API.
2014-05-11core: Remove the cast moduleAlex Crichton-5/+4
This commit revisits the `cast` module in libcore and libstd, and scrutinizes all functions inside of it. The result was to remove the `cast` module entirely, folding all functionality into the `mem` module. Specifically, this is the fate of each function in the `cast` module. * transmute - This function was moved to `mem`, but it is now marked as #[unstable]. This is due to planned changes to the `transmute` function and how it can be invoked (see the #[unstable] comment). For more information, see RFC 5 and #12898 * transmute_copy - This function was moved to `mem`, with clarification that is is not an error to invoke it with T/U that are different sizes, but rather that it is strongly discouraged. This function is now #[stable] * forget - This function was moved to `mem` and marked #[stable] * bump_box_refcount - This function was removed due to the deprecation of managed boxes as well as its questionable utility. * transmute_mut - This function was previously deprecated, and removed as part of this commit. * transmute_mut_unsafe - This function doesn't serve much of a purpose when it can be achieved with an `as` in safe code, so it was removed. * transmute_lifetime - This function was removed because it is likely a strong indication that code is incorrect in the first place. * transmute_mut_lifetime - This function was removed for the same reasons as `transmute_lifetime` * copy_lifetime - This function was moved to `mem`, but it is marked `#[unstable]` now due to the likelihood of being removed in the future if it is found to not be very useful. * copy_mut_lifetime - This function was also moved to `mem`, but had the same treatment as `copy_lifetime`. * copy_lifetime_vec - This function was removed because it is not used today, and its existence is not necessary with DST (copy_lifetime will suffice). In summary, the cast module was stripped down to these functions, and then the functions were moved to the `mem` module. transmute - #[unstable] transmute_copy - #[stable] forget - #[stable] copy_lifetime - #[unstable] copy_mut_lifetime - #[unstable] [breaking-change]
2014-05-10initial port of the exchange allocator to jemallocDaniel Micay-5/+55
In stage0, all allocations are 8-byte aligned. Passing a size and alignment to free is not yet implemented everywhere (0 size and 8 align are used as placeholders). Fixing this is part of #13994. Closes #13616
2014-05-08Move partition/partitioned/concat/connect tests back into sliceKevin Ballard-0/+36
There was no reason to remove them from slice. They're testing methods defined in slice, so that's where they belong. Leave vec with copies of the partition/partitioned tests because it has its own implementation of those methods.
2014-05-08Handle breakage after libcore splitKevin Ballard-29/+5
API Changes: - &[T] and ~[T] no longer support the addition operator (+)
2014-05-08Clean up unused importsKevin Ballard-5/+0
2014-05-08Handle fallout for vector additionKevin Ballard-0/+20
Adding two vectors now results in a Vec<T> instead of a ~[T]. Implement Add on Vec<T>.
2014-05-08More fallout from removing FromIterator on ~[T]Kevin Ballard-42/+42
2014-05-08Move slice::raw::from_buf_raw() to vec::raw::from_buf()Kevin Ballard-55/+0
Change from_buf_raw() to return a Vec<T> instead of a ~[T]. As such, it belongs in vec, in the newly-created vec::raw module.
2014-05-08Rename slice::unzip() to vec::unzip()Kevin Ballard-31/+0
unzip() has nothing to do with slices, so it belongs in vec.
2014-05-08More fallout from removing FromIterator on ~[T]Kevin Ballard-55/+17
A few methods in slice that used to return ~[T] now return Vec<T>: - VectorVector.concat/connect_vec() returns Vec<T> - slice::unzip() returns (Vec<T>, Vec<U>) - ImmutableCloneableVector.partitioned() returns (Vec<T>, Vec<T>) - OwnedVector.partition() returns (Vec<T>, Vec<T>)
2014-05-08Rewrite &[T].to_owned() to allocate directlyKevin Ballard-9/+23
This used to create a Vec<T> and then call .move_iter().collect() to convert to a ~[T]. We can't do that anymore, so construct the ~[T] in place instead. This has the added benefit of avoiding an unnecessary memory copy (from the Vec<T> to the ~[T]).
2014-05-07Test fixes and rebase conflictsAlex Crichton-1/+0
2014-05-07core: Inherit non-allocating slice functionalityAlex Crichton-1553/+18
This commit adds a new trait, MutableVectorAllocating, which represents functions on vectors which can allocate. This is another extension trait to slices which should be removed once a lang item exists for the ~ allocation.
2014-05-07auto merge of #13958 : pcwalton/rust/detilde, r=pcwaltonbors-11/+6
for `~str`/`~[]`. Note that `~self` still remains, since I forgot to add support for `Box<self>` before the snapshot. r? @brson or @alexcrichton or whoever
2014-05-07auto merge of #13914 : alexcrichton/rust/pile-o-rustdoc-fixes, r=brsonbors-4/+4
Lots of assorted things here and there, all the details are in the commits. Closes #11712
2014-05-06librustc: Remove `~EXPR`, `~TYPE`, and `~PAT` from the language, exceptPatrick Walton-11/+6
for `~str`/`~[]`. Note that `~self` still remains, since I forgot to add support for `Box<self>` before the snapshot. How to update your code: * Instead of `~EXPR`, you should write `box EXPR`. * Instead of `~TYPE`, you should write `Box<Type>`. * Instead of `~PATTERN`, you should write `box PATTERN`. [breaking-change]
2014-05-05std: deprecate cast::transmute_mut.Huon Wilson-8/+12
Turning a `&T` into an `&mut T` carries a large risk of undefined behaviour, and needs to be done very very carefully. Providing a convenience function for exactly this task is a bad idea, just tempting people into doing the wrong thing. The right thing is to use types like `Cell`, `RefCell` or `Unsafe`. For memory safety, Rust has that guarantee that `&mut` pointers do not alias with any other pointer, that is, if you have a `&mut T` then that is the only usable pointer to that `T`. This allows Rust to assume that writes through a `&mut T` do not affect the values of any other `&` or `&mut` references. `&` pointers have no guarantees about aliasing or not, so it's entirely possible for the same pointer to be passed into both arguments of a function like fn foo(x: &int, y: &int) { ... } Converting either of `x` or `y` to a `&mut` pointer and modifying it would affect the other value: invalid behaviour. (Similarly, it's undefined behaviour to modify the value of an immutable local, like `let x = 1;`.) At a low-level, the *only* safe way to obtain an `&mut` out of a `&` is using the `Unsafe` type (there are higher level wrappers around it, like `Cell`, `RefCell`, `Mutex` etc.). The `Unsafe` type is registered with the compiler so that it can reason a little about these `&` to `&mut` casts, but it is still up to the user to ensure that the `&mut`s obtained out of an `Unsafe` never alias. (Note that *any* conversion from `&` to `&mut` can be invalid, including a plain `transmute`, or casting `&T` -> `*T` -> `*mut T` -> `&mut T`.) [breaking-change]
2014-05-03rustdoc: Migrate from sundown to hoedownAlex Crichton-4/+4
This primary fix brought on by this upgrade is the proper matching of the ``` and ~~~ doc blocks. This also moves hoedown to a git submodule rather than a bundled repository. Additionally, hoedown is stricter about code blocks, so this ended up fixing a lot of invalid code blocks (ending with " ```" instead of "```", or ending with "~~~~" instead of "~~~"). Closes #12776
2014-05-02Replace most ~exprs with 'box'. #11779Brian Anderson-99/+100
2014-04-28Deprecate the rev_iter pattern in all places where a DoubleEndedIterator is ↵Jonathan S-18/+25
provided (everywhere but treemap) This commit deprecates rev_iter, mut_rev_iter, move_rev_iter everywhere (except treemap) and also deprecates related functions like rsplit, rev_components, and rev_str_components. In every case, these functions can be replaced with the non-reversed form followed by a call to .rev(). To make this more concrete, a translation table for all functional changes necessary follows: * container.rev_iter() -> container.iter().rev() * container.mut_rev_iter() -> container.mut_iter().rev() * container.move_rev_iter() -> container.move_iter().rev() * sliceorstr.rsplit(sep) -> sliceorstr.split(sep).rev() * path.rev_components() -> path.components().rev() * path.rev_str_components() -> path.str_components().rev() In terms of the type system, this change also deprecates any specialized reversed iterator types (except in treemap), opting instead to use Rev directly if any type annotations are needed. However, since methods directly returning reversed iterators are now discouraged, the need for such annotations should be small. However, in those cases, the general pattern for conversion is to take whatever follows Rev in the original reversed name and surround it with Rev<>: * RevComponents<'a> -> Rev<Components<'a>> * RevStrComponents<'a> -> Rev<StrComponents<'a>> * RevItems<'a, T> -> Rev<Items<'a, T>> * etc. The reasoning behind this change is that it makes the standard API much simpler without reducing readability, performance, or power. The presence of functions such as rev_iter adds more boilerplate code to libraries (all of which simply call .iter().rev()), clutters up the documentation, and only helps code by saving two characters. Additionally, the numerous type synonyms that were used to make the type signatures look nice like RevItems add even more boilerplate and clutter up the docs even more. With this change, all that cruft goes away. [breaking-change]
2014-04-28Provide an implementation of DoubleEndedIterator for the results of ↵Jonathan S-58/+53
&[T]::split and &[T]::rsplit This makes the splitting functions in std::slice return DoubleEndedIterators. Unfortunately, splitn and rsplitn cannot provide such an interface and so must return different types. As a result, the following changes were made: * RevSplits was removed in favor of explicitly using Rev * Splits can no longer bound the number of splits done * Splits now implements DoubleEndedIterator * SplitsN was added, taking the role of what both Splits and RevSplits used to be * rsplit returns Rev<Splits<'a, T>> instead of RevSplits<'a, T> * splitn returns SplitsN<'a, T> instead of Splits<'a, T> * rsplitn returns SplitsN<'a, T> instead of RevSplits<'a, T> All functions that were previously implemented on each return value still are, so outside of changing of type annotations, existing code should work out of the box. In the rare case that code relied on the return types of split and splitn or of rsplit and rsplitn being the same, the previous behavior can be emulated by calling splitn or rsplitn with a bount of uint::MAX. The value of this change comes in multiple parts: * Consistency. The splitting code in std::str is structured similarly to the new slice splitting code, having separate CharSplits and CharSplitsN types. * Smaller API. Although this commit doesn't implement it, using a DoubleEndedIterator for splitting means that rsplit, path::RevComponents, path::RevStrComponents, Path::rev_components, and Path::rev_str_components are no longer needed - they can be emulated simply with .rev(). * Power. DoubleEndedIterators are able to traverse the list from both sides at once instead of only forwards or backwards. * Efficiency. For the common case of using split instead of splitn, the iterator is slightly smaller and slightly faster. [breaking-change]
2014-04-26Fixing permutation of small lists, such that [], [x] -> [[]], [[x]], and ↵Wendell Smith-7/+48
updating size_hints. Fixes #13734 and #13759.
2014-04-23auto merge of #13686 : alexcrichton/rust/issue-12224, r=nikomatsakisbors-7/+8
This alters the borrow checker's requirements on invoking closures from requiring an immutable borrow to requiring a unique immutable borrow. This means that it is illegal to invoke a closure through a `&` pointer because there is no guarantee that is not aliased. This does not mean that a closure is required to be in a mutable location, but rather a location which can be proven to be unique (often through a mutable pointer). For example, the following code is unsound and is no longer allowed: type Fn<'a> = ||:'a; fn call(f: |Fn|) { f(|| { f(|| {}) }); } fn main() { call(|a| { a(); }); } There is no replacement for this pattern. For all closures which are stored in structures, it was previously allowed to invoke the closure through `&self` but it now requires invocation through `&mut self`. The standard library has a good number of violations of this new rule, but the fixes will be separated into multiple breaking change commits. Closes #12224
2014-04-23Fix other bugs with new closure borrowingAlex Crichton-5/+6
This fixes various issues throughout the standard distribution and tests.
2014-04-23std: Change RandomAccessIterator to use `&mut self`Alex Crichton-2/+2
Many iterators go through a closure when dealing with the `idx` method, which are invalid after the previous change (closures cannot be invoked through a `&` pointer). This commit alters the `fn idx` method on the RandomAccessIterator to take `&mut self` rather than `&self`. [breaking-change]
2014-04-22Implement Show for &mut [T]Thomas Backman-0/+12
2014-04-18Replace all ~"" with "".to_owned()Richo Healey-15/+15
2014-04-18std: Make ~[T] no longer a growable vectorAlex Crichton-834/+218
This removes all resizability support for ~[T] vectors in preparation of DST. The only growable vector remaining is Vec<T>. In summary, the following methods from ~[T] and various functions were removed. Each method/function has an equivalent on the Vec type in std::vec unless otherwise stated. * slice::OwnedCloneableVector * slice::OwnedEqVector * slice::append * slice::append_one * slice::build (no replacement) * slice::bytes::push_bytes * slice::from_elem * slice::from_fn * slice::with_capacity * ~[T].capacity() * ~[T].clear() * ~[T].dedup() * ~[T].extend() * ~[T].grow() * ~[T].grow_fn() * ~[T].grow_set() * ~[T].insert() * ~[T].pop() * ~[T].push() * ~[T].push_all() * ~[T].push_all_move() * ~[T].remove() * ~[T].reserve() * ~[T].reserve_additional() * ~[T].reserve_exect() * ~[T].retain() * ~[T].set_len() * ~[T].shift() * ~[T].shrink_to_fit() * ~[T].swap_remove() * ~[T].truncate() * ~[T].unshift() * ~str.clear() * ~str.set_len() * ~str.truncate() Note that no other API changes were made. Existing apis that took or returned ~[T] continue to do so. [breaking-change]
2014-04-16Make Vec::clone and slice::to_owned failure-safeJames Miller-10/+15
2014-04-16Improve the copying code for slices and VecJames Miller-4/+16
2014-04-13rustdoc: Fix rendering closures and trait boundsAlex Crichton-2/+7
Closures did not have their bounds printed at all, nor their lifetimes. Trait bounds were also printed in angle brackets rather than after a colon with a '+' inbetween them. Note that on the current task::spawn [1] documentation page, there is no mention of a `Send` bound even though it is crucially important! [1] - http://static.rust-lang.org/doc/master/std/task/fn.task.html
2014-04-11libtest: rename `BenchHarness` to `Bencher`Liigo Zhuang-65/+65
Closes #12640
2014-04-08Register new snapshotsAlex Crichton-13/+13
2014-04-02Fix fallout of requiring uint indicesAlex Crichton-3/+1
2014-04-02rand: remove (almost) all ~[]'s from Vec.Huon Wilson-15/+17
There are a few instances of them in tests which are using functions from std etc. that still are using ~[].
2014-03-31std: Switch field privacy as necessaryAlex Crichton-30/+30
2014-03-30Rename `from_iterator` to `from_iter` for consistency.Brian Anderson-1/+1
2014-03-30Removed deprecated functions `map` and `flat_map` for vectors and slices.Marvin Löbel-80/+1
2014-03-28Convert most code to new inner attribute syntax.Brian Anderson-1/+1
Closes #2569
2014-03-28Rename Pod into CopyFlavio Percoco-3/+3
Summary: So far, we've used the term POD "Plain Old Data" to refer to types that can be safely copied. However, this term is not consistent with the other built-in bounds that use verbs instead. This patch renames the Pod kind into Copy. RFC: 0003-opt-in-builtin-traits Test Plan: make check Reviewers: cmr Differential Revision: http://phabricator.octayn.net/D3