blake2-ppc [Tue, 6 Aug 2013 18:17:06 +0000 (20:17 +0200)]
extra: External iterators for TreeSet set operations
Write external iterators for Difference, Sym. Difference, Intersection
and Union set operations.
These iterators are generic insofar that they could work on any ordered
sequence iterators, even though they are type specialized to the
TreeSetIterator in this case.
Looking at the `check` function in the treeset tests, rustc seems
unwilling to compile a function resembling::
fn check<'a, T: Iterator<&'a int>>(... )
so the tests for these iterators are still running the legacy loop
protocol.
bors [Wed, 7 Aug 2013 20:23:07 +0000 (13:23 -0700)]
auto merge of #8294 : erickt/rust/map-move, r=bblum
According to #7887, we've decided to use the syntax of `fn map<U>(f: &fn(&T) -> U) -> U`, which passes a reference to the closure, and to `fn map_move<U>(f: &fn(T) -> U) -> U` which moves the value into the closure. This PR adds these `.map_move()` functions to `Option` and `Result`.
In addition, it has these other minor features:
* Replaces a couple uses of `option.get()`, `result.get()`, and `result.get_err()` with `option.unwrap()`, `result.unwrap()`, and `result.unwrap_err()`. (See #8268 and #8288 for a more thorough adaptation of this functionality.
* Removes `option.take_map()` and `option.take_map_default()`. These two functions can be easily written as `.take().map_move(...)`.
* Adds a better error message to `result.unwrap()` and `result.unwrap_err()`.
bors [Wed, 7 Aug 2013 13:56:19 +0000 (06:56 -0700)]
auto merge of #8305 : huonw/rust/triage-fixes, r=cmr
The two deletions are because the test cases are very old (still using `class` and modes!), and, as far as I can tell (since they are so old), the areas they test are well tested by other rpass tests.
bors [Wed, 7 Aug 2013 07:56:18 +0000 (00:56 -0700)]
auto merge of #8285 : huonw/rust/deriving+++, r=alexcrichton
Some general clean-up relating to deriving:
- `TotalOrd` was too eager, and evaluated the `.cmp` call for every field, even if it could short-circuit earlier.
- the pointer types didn't have impls for `TotalOrd` or `TotalEq`.
- the Makefiles didn't reach deep enough into libsyntax for dependencies.
(Split out from https://github.com/mozilla/rust/pull/8258.)
bors [Wed, 7 Aug 2013 04:05:11 +0000 (21:05 -0700)]
auto merge of #8287 : sfackler/rust/hex, r=alexcrichton
FromHex ignores whitespace and parses either upper or lower case hex
digits. ToHex outputs lower case hex digits with no whitespace. Unlike
ToBase64, ToHex doesn't allow you to configure the output format. I
don't feel that it's super useful in this case.
Daniel Micay [Tue, 6 Aug 2013 03:43:06 +0000 (23:43 -0400)]
remove `extra::iter`
This module provided adaptors for the old internal iterator protocol,
but they proved to be quite unreadable and are not generic enough to
handle borrowed pointers well.
Since Rust no longer defines an internal iteration protocol, I don't
think there's going to be any reuse via these adaptors.
bors [Tue, 6 Aug 2013 17:32:00 +0000 (10:32 -0700)]
auto merge of #8317 : bblum/rust/fast-spawn-unlinked, r=brson
This lazily initializes the taskgroup structs for ```spawn_unlinked``` tasks. If such a task never spawns another task linked to it (or a descendant of it), its taskgroup is simply never initialized at all. Also if an unlinked task spawns another unlinked task, neither of them will need to initialize their taskgroups. This works for the main task too.
I benchmarked this with the following test case and observed a ~~21% speedup (average over 4 runs: 7.85 sec -> 6.20 sec, 2.5 GHz)~~ 11% speedup, see comment below.
```
use std::task;
use std::cell::Cell;
use std::rt::comm;
static NUM: uint = 1024*256;
fn run(f: ~fn()) {
let mut t = task::task();
t.unlinked();
t.spawn(f);
}
fn main() {
do NUM.times {
let (p,c) = comm::oneshot();
let c = Cell::new(c);
do run { c.take().send(()); }
p.recv();
}
}
```
Steven Fackler [Mon, 5 Aug 2013 05:25:15 +0000 (01:25 -0400)]
Removed convenience encoding trait impls
Encoding should really only be done from [u8]<->str. The extra
convenience implementations don't really have a place, especially since
they're so trivial.
Steven Fackler [Mon, 5 Aug 2013 03:51:26 +0000 (23:51 -0400)]
ToBase64 and ToHex perf improvements
The overhead of str::push_char is high enough to cripple the performance
of these two functions. I've switched them to build the output in a
~[u8] and then convert to a string later. Since we know exactly the
bytes going into the vector, we can use the unsafe version to avoid the
is_utf8 check.
I could have riced it further with vec::raw::get, but it only added
~10MB/s so I didn't think it was worth it. ToHex is still ~30% slower
than FromHex, which is puzzling.
Steven Fackler [Sun, 4 Aug 2013 18:42:39 +0000 (14:42 -0400)]
Added hexadecimal encoding module
FromHex ignores whitespace and parses either upper or lower case hex
digits. ToHex outputs lower case hex digits with no whitespace. Unlike
ToBase64, ToHex doesn't allow you to configure the output format. I
don't feel that it's super useful in this case.
bors [Tue, 6 Aug 2013 12:26:01 +0000 (05:26 -0700)]
auto merge of #8308 : blake2-ppc/rust/str-slice-bytes, r=alexcrichton
`fn slice_bytes` is marked unsafe since it allows violating the valid
string encoding property; but the function did also allow extending the
lifetime of the slice by mistake, since it's returning `&str`.
Use the annotation `slice_bytes<'a>(&'a str, ...) -> &'a str` so
that all uses of `slice_bytes` are region checked correctly.
blake2-ppc [Sat, 3 Aug 2013 17:40:20 +0000 (19:40 +0200)]
std: Add .consume_iter() for Option, to make it reusable
Let Option be a base for a widely useful one- or zero- item iterator.
Refactor OptionIterator to support any generic element type, so the same
iterator impl can be used for both &T, &mut T and T iterators.
bors [Mon, 5 Aug 2013 23:47:01 +0000 (16:47 -0700)]
auto merge of #8288 : Kimundi/rust/opteitres4, r=brson
This is an alternative version to https://github.com/mozilla/rust/pull/8268, where instead of transitioning to `get()` completely, I transitioned to `unwrap()` completely.
My reasoning for also opening this PR is that having two different functions with identical behavior on a common datatype is bad for consistency and confusing for users, and should be solved as soon as possible. The fact that apparently half the code uses `get()`, and the other half `unwrap()` only makes it worse.
If the final naming decision ends up different, there needs to be a big renaming anyway, but until then it should at least be consistent.
---
- Made naming schemes consistent between Option, Result and Either
- Lifted the quality of the either and result module to that of option
- Changed Options Add implementation to work like the maybe Monad (return None if any of the inputs is None)
See https://github.com/mozilla/rust/issues/6002, especially my last comment.
- Removed duplicate Option::get and renamed all related functions to use the term `unwrap` instead
See also https://github.com/mozilla/rust/issues/7887.
Todo:
Adding testcases for all function in the three modules. Even without the few functions I added, the coverage wasn't complete to begin with. But I'd rather do that as a follow up PR, I've touched to much code here already, need to go through them again later.
Marvin Löbel [Sat, 3 Aug 2013 23:59:24 +0000 (01:59 +0200)]
Updated std::Option, std::Either and std::Result
- Made naming schemes consistent between Option, Result and Either
- Changed Options Add implementation to work like the maybe monad (return None if any of the inputs is None)
- Removed duplicate Option::get and renamed all related functions to use the term `unwrap` instead
blake2-ppc [Mon, 5 Aug 2013 15:52:03 +0000 (17:52 +0200)]
std: Use correct lifetime parameter on str::raw::slice_bytes
fn slice_bytes is marked unsafe since it allows violating the valid
string encoding property; but the function did also allow extending the
lifetime of the slice by mistake, since it's returning `&str`.
Use the annotation `slice_bytes<'a>(&'a str, ...) -> &'a str` so
that all uses of slice_bytes are region checked correctly.
bors [Mon, 5 Aug 2013 13:22:57 +0000 (06:22 -0700)]
auto merge of #8183 : omasanori/rust/migrate-new, r=sanxiyn
It seems that relatively new code uses `Foo::new()` instead of `Foo()` so I wrote a patch to migrate some structs to the former style.
Is it a right direction? If there are any guidelines not to use new()-style, could you add them to the [style guide](https://github.com/omasanori/rust/wiki/Note-style-guide)?