rustpkg now searches for package directories in ./src rather than
in . . I also added a rudimentary RUST_PATH that's currently
hard-wired to the current directory. rustpkg now uses src/, lib/,
and build/ directories as described in the manual.
Most of the existing test scenarios build now; the README file
(in a separate commit) explains which ones.
This brings them in line with the quot and rem traits, and is be better for large Integer types like BigInt and BigUint because they don't need to be copied unnecessarily.
'Natural' normally means 'positive integer' in mathematics. It is therefore strange to implement it on signed integer types. 'Integer' is probably a better choice.
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).
This moves all the basic random value generation into the Rand instances for
each type and then removes the `gen_int`, `gen_char` (etc) methods on RngUtil,
leaving only the generic `gen` and the more specialised methods.
Also, removes some imports that are redundant due to a `use core::prelude::*`
statement.
As part of the numeric trait reform (see issue #4819), I have added the following traits to `core::num` and implemented them for the appropriate types:
~~~rust
pub trait Signed: Num
+ Neg<Self> {
fn abs(&self) -> Self;
fn signum(&self) -> Self;
fn is_positive(&self) -> bool;
fn is_negative(&self) -> bool;
}
pub trait Unsigned: Num {}
pub trait Natural: Num
+ Ord
+ Quot<Self,Self>
+ Rem<Self,Self> {
fn div(&self, other: Self) -> Self;
fn modulo(&self, other: Self) -> Self;
fn div_mod(&self, other: Self) -> (Self,Self);
fn quot_rem(&self, other: Self) -> (Self,Self);
fn gcd(&self, other: Self) -> Self;
fn lcm(&self, other: Self) -> Self;
fn divisible_by(&self, other: Self) -> bool;
fn is_even(&self) -> bool;
fn is_odd(&self) -> bool;
}
~~~
I have not implemented `Natural` for `BigInt` and `BigUInt` because they're a little over my head. Help with this would be most appreciated.
This adds the following methods to ints and uints:
- div
- modulo
- div_mod
- quot_rem
- gcd
- lcm
- divisible_by
- is_even
- is_odd
I have not implemented Natural for BigInt and BigUInt because they're a little over my head.
Because unsafe functions are never warned about, then all `unsafe` blocks in unsafe functions should definitely be warned about (no need to be redundant). This fixes this case, adds tests, cleans up remaining cases, and then fixes a few other import warnings being spit out.
This fixes#5976.
It also removes `os::waitpid` in favour of (the existing) `run::waitpid`. I included this change because I figured it is kind of related.
r?
- The return value meant different things on different
platforms (on windows, it was the exit code, on unix it was
the status information returned from waitpid).
- It was undocumented.
- There also exists run::waitpid, which does much the same
thing but has a more consistent return value and also some
documentation.
Closes#2697
I guess all of the uses weren't around any more, because everything continued to compile (at least on OSX). If bors doesn't like it for another platform I can try to track it down as well.
This reverts commit 6030e3982a.
This reorders error messages in ways that aren't intended. A more satisfying solution will require an interface that allows diagnostics to be grouped together, so that messages that logically belong together aren't reordered.
#4569
