Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.
Closes#6117.
The test is reduced from a doc test, but making it separate ensures that
(1) unrelated changes to the docs won't leave this case uncovered, and
(2) the nature of any future failures will be more obvious to whoever
sees the tree on fire as a result.
Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.
Closes#6117.
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.
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`
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).
