Adds an `uninit` intrinsic.
It's just an empty function, so llvm optimizes it down to nothing.
I changed all of the `init` intrinsic usages to `uninit` where it seemed appropriate to.
I removed some of the copies, but most are just made explicit. The usage in `libcore` was already fixed, but the attribute was only set to warn (not removed).
Hi there,
Really enjoying Rust. Noticed a few typos so I searched around for a few more--here's some fixes.
Ran `make check` and got `summary of 24 test runs: 4868 passed; 0 failed; 330 ignored`.
Thanks!
Sean
This is part of the redesign of the numeric traits tracked in issue #4819.
Renamed:
- `Exponential::expm1` -> `Float::exp_m1` - for consistency with underscore usage elsewhere
- `Exponential::log` -> `Exponential::ln` - a less ambiguous name for the natural logarithm
- `{float, f64, f32}::logarithm` -> `Exponential::log` - for arbitrary base logarithms
- `Real::log_2` -> `Real::ln_2` - for consistency with `ln`
- `Real::log_10` -> `Real::ln_10` - for consistency with `ln`
Added:
- `Signed::abs_sub` - wraps libm's `fdim` function
- `Float::is_normal` - returns `true` if the number is neither zero, infinite, subnormal or NaN
- `Float::classify` - returns the floating point category of the number
- `Float::ln_1p` - returns the natural logarithm of the number plus one
Closes#5392 and #5393
I implemented the pop/swap methods for TrieMap/TreeMap/SmallIntMap, and I also updated all of them such that pop isn't just a remove/insert, but rather it's all done in one operation.
One thing I did notice is that with default methods it'd be really nice to define `insert` and `remove` in terms of `pop` and `swap` (or vice versa, just to have them available).
To provide a reference counted pointer type with deterministic
destruction once managed boxes are switched over to a garbage
collector. Unlike managed boxes, these can be moved instead of just
copied/cloned which is helpful for avoiding reference counts.
Needs #5601 to be fixed in order for safety to be provided without the current ugly workaround of making the pointers contain `Option<@()>` and `Option<@mut ()>` (which are just set to `None`).
@brson: r?
To provide a reference counted pointer type with deterministic
destruction once managed boxes are switched over to a garbage
collector. Unlike managed boxes, these can be moved instead of just
copied/cloned which is helpful for avoiding reference counts.
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).
From a cursory `git grep` this removes the last part of `core` that requires on `@` (other than `io` and the task local data section).
It renames `RandRes` to ~~StdRng~~ `IsaacRng` and `XorShiftState` to `XorShiftRng` as well as moving their constructors to static methods. To go with this, it adds `rng()` which is designed to be used when the programmer just wants a random number generator, without caring about which exact algorithm is being used.
It also removes all the `gen_int`, `gen_uint`, `gen_char` (etc) methods on `RngUtil` (by moving the defintions to the actual `Rand` instances). The replacement is using `RngUtil::gen`, either type-inferred or with an annotation (`rng.gen::<uint>()`).
I tried to have the `Rng` and `RngUtil` traits exported by `core::prelude` (since `core::rand` (except for `random()`) is useless without them), but this caused [an explosion of (seemingly unrelated) `error: unresolved import`'s](https://gist.github.com/5451839).
