Change to resolve and update compiler and libs for uses.
[breaking-change]
Enum variants are now in both the value and type namespaces. This means that
if you have a variant with the same name as a type in scope in a module, you
will get a name clash and thus an error. The solution is to either rename the
type or the variant.
This is part of the migration of crates into the Cargo ecosystem. There
is now an external repository https://github.com/rust-lang/num for bignums.
The single use of libnum elsewhere in the repository is for a shootout
benchmark, which is being moved into the external crate.
Due to deprecation, this is a:
[breaking-change]
This unifies the `non_snake_case_functions` and `uppercase_variables` lints
into one lint, `non_snake_case`. It also now checks for non-snake-case modules.
This also extends the non-camel-case types lint to check type parameters, and
merges the `non_uppercase_pattern_statics` lint into the
`non_uppercase_statics` lint.
Because the `uppercase_variables` lint is now part of the `non_snake_case`
lint, all non-snake-case variables that start with lowercase characters (such
as `fooBar`) will now trigger the `non_snake_case` lint.
New code should be updated to use the new `non_snake_case` lint instead of the
previous `non_snake_case_functions` and `uppercase_variables` lints. All use of
the `non_uppercase_pattern_statics` should be replaced with the
`non_uppercase_statics` lint. Any code that previously contained non-snake-case
module or variable names should be updated to use snake case names or disable
the `non_snake_case` lint. Any code with non-camel-case type parameters should
be changed to use camel case or disable the `non_camel_case_types` lint.
[breaking-change]
The implemented fix rounds half-way cases away from zero as described in
the original comments.
This rounding algorithm is sometimes called arithmetic rounding. It is
described further here:
http://en.wikipedia.org/wiki/Rounding#Round_half_away_from_zero
I also added several new tests to prevent regressions.
Pretty self-explanatory. Only annoying thing is that it *seems* that I had to add `#![feature(default_type_params)]` to libnum because of Hasher. Don't know if there's a way around that.
Fix#16551
It is being changed because the previous wording was ambiguous.
`a.divides(b)` implied `a % b == 0` but it sounds like the other way
around. `9.divides(&3) == true` but we might read that as
"does 9 divide 3?". It has been renamed to sidestep the ambiguity.
Work around the change by using `is_multiple_of` instead.
[breaking-change]
Simple usage examples for Integer methods. Also group `div_rem` and `div_mod_floor` together at the bottom of the trait, to reflect the documentation rendering.
I ended up altering the semantics of Json's PartialOrd implementation.
It used to be the case that Null < Null, but I can't think of any reason
for an ordering other than the default one so I just switched it over to
using the derived implementation.
This also fixes broken `PartialOrd` implementations for `Vec` and
`TreeMap`.
RFC: 0028-partial-cmp
floating point numbers for real.
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes#15201.
[breaking-change]
The following are unstable:
- core::int, i8, i16, i32, i64
- core::uint, u8, u16, u32, u64
- core::int::{BITS, BYTES, MIN, MAX}, etc.
- std::int, i8, i16, i32, i64
- std::uint, u8, u16, u32, u64
The following are experimental:
- std::from_str::FromStr and impls - may need to return Result instead of Option
- std::int::parse_bytes, etc. - ditto
- std::num::FromStrRadix and impls - ditto
- std::num::from_str_radix - ditto
The following are deprecated:
- std::num::ToStrRadix and imples - Wrapper around fmt::radix. Wrong name (Str vs String)
See https://github.com/rust-lang/rust/wiki/Meeting-API-review-2014-06-23#uint
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes#6023.
[breaking-change]
This creates a stability baseline for all crates that we distribute that are not `std`. In general, all library code must start as experimental and progress in stages to become stable.
The following features have been removed
* box [a, b, c]
* ~[a, b, c]
* box [a, ..N]
* ~[a, ..N]
* ~[T] (as a type)
* deprecated_owned_vector lint
All users of ~[T] should move to using Vec<T> instead.
Steven Fackler