| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use the iterator version instead of the old uint::/int::range_step
functions.
|
|
The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
|
|
If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:
fn foo<E: Extendable<int, Range<int>> +
Extendable<int, Map<&'self int, int, VecIterator<int>>>
(e: &mut E, ...) { ... }
since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).
This patch changes it to:
fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
|
|
|
|
cc #5898
|
|
|
|
|
|
Range is now invertable as long as its element type conforms to Integer.
Remove int::range_rev() et al in favor of range().invert().
|
|
Fix inappropriate for-range loops to use for-iterator constructs (or
other appropriate solution) instead.
|
|
|
|
Closes #5506.
|
|
|
|
this has been replaced by `for`
|
|
Map::contains_key can be implemented with Map::find.
Remove several implementations of contains_key.
|
|
|
|
Map::contains_key can be implemented with Map::find.
Remove several implementations of contains_key.
|
|
|
|
|
|
|
|
|
|
A couple of implementations of Container::is_empty weren't exactly
self.len() == 0 so I left them alone (e.g. Treemap).
|
|
|
|
|
|
pnkfelix/rust/fsk-invert-range-rev-halfclosedness-issue5270-2ndpr, r=cmr
Changes int/uint range_rev to iterate over range `(hi,lo]` instead of `[hi,lo)`.
Fix #5270.
Also:
* Adds unit tests for int/uint range functions
* Updates the uses of `range_rev` to account for the new semantics. (Note that pretty much all of the updates there were strict improvements to the code in question; yay!)
* Exposes new function, `range_step_inclusive`, which does the range `[hi,lo]`, (at least when `hi-lo` is a multiple of the `step` parameter).
* Special-cases when `|step| == 1` removing unnecessary bounds-check. (I did not check whether LLVM was already performing this optimization; I figure it would be a net win to not leave that analysis to the compiler. If reviewer objects, I can easily remove that from the refactored code.)
(This pull request is a rebased version of PR #7524, which went stale due to recent unrelated changes to num libraries.)
|
|
Added Iterators for HashMap/Set, TreeMap/Set, TrieMap/Set, and PriorityQueue as per Issue #7626
|
|
|
|
|
|
Fixes most of #4989. I didn't add Persistent{Set,Map} since the only
persistent data structure is fun_treemap and its functionality is
currently too limited to build a trait out of.
|
|
|
|
|
|
|
|
for making them noncopyable.
|
|
the maps are being migrated to external iterators
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
|
|
Fix a laundry list of warnings involving unused imports that glutted
up compilation output. There are more, but there seems to be some
false positives (where 'remedy' appears to break the build), but this
particular set of fixes seems safe.
|
|
Adds documentation for various things that I understand.
Adds #[allow(missing_doc)] for lots of things that I don't understand.
|
|
|
|
This only changes the directory names; it does not change the "real"
metadata names.
|
