Add method .move_from() to MutableVector, which consumes another vector
and moves elements into the receiver.
Add new trait MutableCloneableVector with one method .copy_from(), which
clones elements from another vector into the receiver.
This sets the `get_tydesc()` return type correctly and removes the intrinsic module. See #3730, #3475.
Update: this now also removes the unused shape fields in tydescs.
the `test/run-pass/class-trait-bounded-param.rs` test was xfailed and
written in an ancient dialect of Rust so I've just removed it
this also removes `to_vec` from DList because it's provided by
`std::iter::to_vec`
an Iterator implementation is added for OptVec but some transitional
internal iterator methods are still left
To achieve this, the following changes were made:
* Move TyDesc, TyVisitor and Opaque to std::unstable::intrinsics
* Convert TyDesc, TyVisitor and Opaque to lang items instead of specially
handling the intrinsics module
* Removed TypeDesc, FreeGlue and get_type_desc() from sys
Fixes#3475.
I removed the `static-method-test.rs` test because it was heavily based
on `BaseIter` and there are plenty of other more complex uses of static
methods anyway.
The removed test for issue #2611 is well covered by the `std::iterator`
module itself.
This adds the `count` method to `IteratorUtil` to replace `EqIter`.
This allows mass-initialization of large structs without having to specify all the fields.
I'm a bit hesitant, but I wanted to get this out there. I don't really like using the `Zero` trait, because it doesn't really make sense for a type like `HashMap` to use `Zero` as the 'blank allocation' trait. In theory there'd be a new trait, but then that's adding cruft to the language which may not necessarily need to be there.
I do think that this can be useful, but I only implemented `Zero` on the basic types where I thought it made sense, so it may not be all that usable yet. (opinions?)
This is caused by StrVector having a generic implementation for &[S]
and so #5898 means that method resolution of ~[~[1]].concat() sees that
both StrVector and VectorVector have methods that (superficially) match.
They are now connect_vec and concat_vec, which means that they can actually be
called.
This is caused by StrVector having a generic implementation for &[S]
and so #5898 means that method resolution of ~[~[1]].concat() sees that
both StrVector and VectorVector have methods that (superficially) match.
They are now connect_vec and concat_vec, which means that they can actually be
called.
This fixes the strange random crashes in compile-fail tests.
This reverts commit 96cd61ad03.
Conflicts:
src/librustc/driver/driver.rs
src/libstd/str.rs
src/libsyntax/ext/quote.rs
