* stop using an atomic counter, this has a significant cost and
valgrind will already catch these leaks
* remove the extra layer of function calls
* remove the assert of non-null in free, freeing null is well defined
but throwing a failure from free will not be
* stop initializing the `prev`/`next` pointers
* abort on out-of-memory, failing won't necessarily work
I almost got locked out of my machine because I misunderstood the purpose of the function and called it with a limit of uint::max_value, which turned this function into an almost endless loop.
Instead of determining paths from the path tag, we iterate through
modules' children recursively in the metadata. This will allow for
lazy external module resolution.
`max_by` method returns the element that gives the maximum value from the specfied function.
`max_by`/`min_by` are convenient when you want to get the value which has greatest/smallest scores.
Inspired by [ruby's Enumerable module](http://ruby-doc.org/core-2.0/Enumerable.html).
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.
flat_map_ produces an iterator that maps each element to an iterator,
and yields the elements of the produced iterators.
This is the monadic bind :: M a -> (a -> M b) -> M b for iterators.
Named just like the vec method, but with a trailing underline until the
method resolution bug is resolved.
We discussed the name chain_map, but I decided to go with flat_map_ for consistency with vec.
Since it.map(f).flatten() would be the same as it.flat_map(f), we could choose
to just implement a flatten method instead. Either way the possibilities are the same but flat_map is more convenient.
Reopening of #7031, Closes#6963
I imagine though that this will bounce in bors once or twice... Because attributes can't be cfg(stage0)'d off, there's temporarily a lot of new stage0/stage1+ code.
This adds a `#[no_drop_flag]` attribute. This attribute tells the compiler to omit the drop flag from the struct, if it has a destructor. When the destructor is run, instead of setting the drop flag, it instead zeroes-out the struct. This means the destructor can run multiple times and therefore it is up to the developer to use it safely.
The primary usage case for this is smart-pointer types like `Rc<T>` as the extra flag caused the struct to be 1 word larger because of alignment.
This closes#7271 and #7138
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.
flat_map_ produces an iterator that maps each element to an iterator,
and yields the elements of the produced iterators.
This is the monadic bind :: M a -> (a -> M b) -> M b for iterators.
Named just like the vec method, but with a trailing underline until the
method resolution bug is resolved.
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
This commit adds filtered method for Option type. It is not exactly necessary (chain method can be used instead), however I believe that this approach using extra filtered method is more convinient.
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.
This fixes part of #3730, but not all.
Also changes the TyDesc struct to be equivalent with the generated
code, with the hope that the above issue may one day be closed for good,
i.e. that the TyDesc type can completely be specified in the Rust
sources and not be generated.
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.
