John Clements [Thu, 18 Apr 2013 20:44:49 +0000 (13:44 -0700)]
This test case is obsolete for two reasons
First, it refers to a feature (trait bounds on type parameters) that's
apparently no longer in the language. Second, if I understand the issue
correctly, it should never have been a "run-pass" test because it was
supposed to fail.
auto merge of #6108 : gifnksm/rust/bigint-shift-bug, r=brson
`std::bigint` contains the following code.
```rust
borrow = *elem << (uint::bits - n_bits);
```
The code above contains a bug that the value of the right operand of the shift operator exceeds the size of the left operand,
because sizeof(*elem) == 32, and 0 <= n_bits < 32 in 64bit architecture.
If `--opt-level` option is not given to rustc, the code above runs as if the right operand is `(uint::bits - n_bits) % 32`,
but if --opt-level is given, `borrow` is always zero.
I wonder why this bug is not catched in the libstd's testsuite (I try the `rustc --test --opt-level=2 bigint.rs` before fixing the bug,
but the unittest passes normally.)
This pull request also removes the implicit vector copies in `bigint.rs`.
auto merge of #6073 : huonw/rust/core-rust-isaac, r=pcwalton
This replaces the wrapper around the runtime RNG with a pure Rust implementation of the same algorithm. This is much faster (up to 5x), and is hopefully safer.
There is still (a little) room for optimisation: testing by summing 100,000,000 random `u32`s indicates this is about ~~40-50%~~ 10% slower than the pure C implementation (running as standalone executable, not in the runtime).
(Only 6d50d55 is part of this PR, the first two are from #6058, but are required for the rt rng to be correct to compare against in the tests.)
Huon Wilson [Fri, 26 Apr 2013 13:23:49 +0000 (23:23 +1000)]
core: a pure Rust implementation of the ISAAC RNG.
This replaces the wrapper around the runtime RNG with a pure Rust
implementation of the same algorithm. This is faster (up to 5x), and
is hopefully safer.
There is still much room for optimisation: testing by summing 100,000,000
random `u32`s indicates this is about 40-50% slower than the pure C
implementation (running as standalone executable, not in the runtime).
auto merge of #6110 : bjz/rust/numeric-traits, r=pcwalton
As discussed on issue #4819, I have created four new traits: `Algebraic`, `Trigonometric`, `Exponential` and `Hyperbolic`, and moved the appropriate methods into them from `Real`.
There was some discussion over whether we should shorten the names, for example `Trig` and `Exp`. No abbreviations have been agreed on yet, but this could be considered in the future.
Additionally, `Integer::divisible_by` has been renamed to `Integer::is_multiple_of`.
auto merge of #6099 : danluu/rust/xfail_clone, r=catamorphism
One of the tests seems to have no current equivalent that's similar. Please let me know if that's incorrect, and I'll try fixing it instead of deleting it. I suppose a struct could be used instead of `any` and `match type`, but it seems like the original intent of the test was to exercise `match type`
After discussions on IRC and #4819, we have decided to revert this change. This is due to the traits expressing different ideas and because hyperbolic functions are not trivially implementable from exponential functions for floating-point types.
The Hyperbolic Functions are trivially implemented in terms of `exp`, so it's simpler to group them the Exponential trait. In the future these would have default implementations.
auto merge of #6083 : jbclements/rust/parser-cleanup, r=jbclements
r? @pcwalton
A month's worth of parser cleanup here. Much of this is new comments and renaming. A number of these commits also remove unneeded code. Probably the biggest refactor here is splitting "parse_item_or_view_item" into two functions; it turns out that the only overlap between items in foreign modules and items in regular modules was macros, so this refactor should make things substantially easier for future maintenance.
The code above contains a bug that the value of the right operand of the shift operator exceeds the size of the left operand,
because sizeof(*elem) == 32, and 0 <= n_bits < 32 in 64bit architecture.
If `--opt-level` option is not given to rustc, the code above runs as if the right operand is `(uint::bits - n_bits) % 32`,
but if --opt-level is given, `borrow` is always zero.
I wonder why this bug is not catched in the libstd's testsuite (I try the `rustc --test --opt-level=2 bigint.rs` before fixing the bug,
but the unittest passes normally.)
auto merge of #6056 : thestinger/rust/iter, r=catamorphism
The existing adaptors like `map` in the `iter` module are very flawed because they only work for `BaseIter` implementations. There are many internal iterator implementations in the standard library like the set methods (`difference`, `symmetric_difference`, `intersection`, `union`) and the `range` functions that only share the `for` loop protocol in common.
The internal iterator adaptors should be implemented to work on any implementation of that protocol, rather than just a method called `each` taking `&self`.
This just moves `iter.rs` to `old_iter.rs` and begins work on documenting and implementing a nicer module.
John Clements [Wed, 17 Apr 2013 19:24:49 +0000 (12:24 -0700)]
remove unused functions, fix tiny lexing bug
before this change, the parser would parse 14.a() as a method call, but
would parse 14.ø() as the floating-point number 14. followed by a function
call. This is because it was checking is_alpha, rather than ident_start,
and was therefore wrong with respect to unicode.
John Clements [Sat, 6 Apr 2013 00:31:52 +0000 (17:31 -0700)]
undo abstraction over whether to parse attrs in a block
In principle, it seems like a nice idea to abstract over the two
functions that parse blocks (one with inner attrs allowed, one not).
However, the existing one wound up making things more complex than
just having two separate functions, especially after the obsolete
syntax is (will be) removed.
John Clements [Fri, 29 Mar 2013 17:04:48 +0000 (10:04 -0700)]
get rid of prec.rs
prec.rs no longer had much to do with precedence; the token->binop
function fits better in token.rs, and the one-liner defining the
precedence of 'as' can go next to the other precedence stuff in
ast_util.rs
auto merge of #6082 : catamorphism/rust/mkdir_recursive, r=brson
r? @brson mkdir_recursive creates a directory as well as any of its
parent directories that don't exist already. Seems like a useful
thing to have in core.
auto merge of #6071 : bjz/rust/numeric-traits, r=graydon
As part of the numeric trait reform (see issue #4819), I have added the following traits to `core::num` and implemented them for Rust's primitive numeric types:
fn mul_add(&self, a: Self, b: Self) -> Self;
fn next_after(&self, other: Self) -> Self;
}
~~~
Note: I'm not sure my implementation for `BitCount::trailing_zeros` and `BitCount::leading_zeros` is correct for uints. I also need some assistance creating appropriate unit tests for them.
More work needs to be done in implementing specialized primitive floating-point and integer methods, but I'm beginning to reach the limits of my knowledge. Please leave your suggestions/critiques/ideas on #4819 if you have them – I'd very much appreciate hearing them.
This is a temporary trait until we have default methods. We don't want to encumber all implementors of Ord by requiring them to implement these functions, but at the same time we want to be able to take advantage of the speed of the specific numeric functions (like the `fmin` and `fmax` intrinsics).