I just had `git apply` fix most of them and then did a quick skim over the diff to fix a few cases where it did the wrong thing (mostly replacing tabs with 4 spaces, when someone's editor had them at 8 spaces).
The install command should work now, though it only installs
in-place (anything else has to wait until I implement RUST_PATH).
Also including:
core: Add remove_directory_recursive, change copy_file
Make copy_file preserve permissions, and add a remove_directory_recursive
function.
After much discussion on IRC and #4819, we have decided to revert to the old naming of the `/` operator. This does not change its behavior. In making this change, we also have had to rename some of the methods in the `Integer` trait. Here is a list of the methods that have changed:
- `Quot::quot` -> `Div::div`
- `Rem::rem` - stays the same
- `Integer::quot_rem` -> `Integer::div_rem`
- `Integer::div` -> `Integer::div_floor`
- `Integer::modulo` -> `Integer::mod_floor`
- `Integer::div_mod` -> `Integer::div_mod_floor`
`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`.
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`.
~~~rust
pub trait Algebraic {
fn pow(&self, n: Self) -> Self;
fn sqrt(&self) -> Self;
fn rsqrt(&self) -> Self;
fn cbrt(&self) -> Self;
fn hypot(&self, other: Self) -> Self;
}
pub trait Trigonometric {
fn sin(&self) -> Self;
fn cos(&self) -> Self;
fn tan(&self) -> Self;
fn asin(&self) -> Self;
fn acos(&self) -> Self;
fn atan(&self) -> Self;
fn atan2(&self, other: Self) -> Self;
}
pub trait Exponential {
fn exp(&self) -> Self;
fn exp2(&self) -> Self;
fn expm1(&self) -> Self;
fn log(&self) -> Self;
fn log2(&self) -> Self;
fn log10(&self) -> Self;
}
pub trait Hyperbolic: Exponential {
fn sinh(&self) -> Self;
fn cosh(&self) -> Self;
fn tanh(&self) -> Self;
}
~~~
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`.
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.)
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:
~~~rust
pub trait Bitwise: Not<Self>
+ BitAnd<Self,Self>
+ BitOr<Self,Self>
+ BitXor<Self,Self>
+ Shl<Self,Self>
+ Shr<Self,Self> {}
pub trait BitCount {
fn population_count(&self) -> Self;
fn leading_zeros(&self) -> Self;
fn trailing_zeros(&self) -> Self;
}
pub trait Bounded {
fn min_value() -> Self;
fn max_value() -> Self;
}
pub trait Primitive: Num
+ NumCast
+ Bounded
+ Neg<Self>
+ Add<Self,Self>
+ Sub<Self,Self>
+ Mul<Self,Self>
+ Quot<Self,Self>
+ Rem<Self,Self> {
fn bits() -> uint;
fn bytes() -> uint;
}
pub trait Int: Integer
+ Primitive
+ Bitwise
+ BitCount {}
pub trait Float: Real
+ Signed
+ Primitive {
fn NaN() -> Self;
fn infinity() -> Self;
fn neg_infinity() -> Self;
fn neg_zero() -> Self;
fn is_NaN(&self) -> bool;
fn is_infinite(&self) -> bool;
fn is_finite(&self) -> bool;
fn mantissa_digits() -> uint;
fn digits() -> uint;
fn epsilon() -> Self;
fn min_exp() -> int;
fn max_exp() -> int;
fn min_10_exp() -> int;
fn max_10_exp() -> int;
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.
I have also added an `Orderable` trait:
~~~rust
pub trait Orderable: Ord {
fn min(&self, other: &Self) -> Self;
fn max(&self, other: &Self) -> Self;
fn clamp(&self, mn: &Self, mx: &Self) -> Self;
}
~~~
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).
