Previously Int inherited from PartialOrd (via Primitive)
but not Ord.  But integers have a total order, so
inheriting from Ord is appropriate. Fixes #18776.

https://github.com/rust-lang/rfcs/pull/221

The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.

Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.

We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.

To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:

    grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'

You can of course also do this by hand.

[breaking-change]

The "/" was probably generated by a `gq` in vim.

as far as I can tell.

Closes #9987.

Remove ~~~ for code block specification. Use /// Over /** */ for doc
blocks.

Fixes rust-lang/rfcs#224

Use proper argument names and unbackquote the word "zero" because it is
not an identifier.
Signed-off-by: NOGINO Masanori <masanori.ogino@gmail.com>

This removes the special casing for `float`s where it was not necessary, as
`-0.0 == 0.0`.

Add additional rotation tests

Libcore's test infrastructure is complicated by the fact that many lang
items are defined in the crate. The current approach (realcore/realstd
imports) is hacky and hard to work with (tests inside of core::cmp
haven't been run for months!).

Moving tests to a separate crate does mean that they can only test the
public API of libcore, but I don't feel that that is too much of an
issue. The only tests that I had to get rid of were some checking the
various numeric formatters, but those are also exercised through normal
format! calls in other tests.

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]

The consensus on #14917 was that the proposed names were too long.

This reduces the complexity of the trait hierarchy.

The `Bitwise::swap_bytes` method was also moved into the `ByteOrder` trait. This was because it works on the byte level rather than the bit level.

Now that rustdoc understands proper language tags
as the code not being Rust, we can tag everything
properly.

This change tags examples in other languages by
their language. Plain notations are marked as `text`.
Console examples are marked as `console`.

Also fix markdown.rs to not highlight non-rust code.

This is part of the ongoing renaming of the equality traits. See #12517 for more
details. All code using Eq/Ord will temporarily need to move to Partial{Eq,Ord}
or the Total{Eq,Ord} traits. The Total traits will soon be renamed to {Eq,Ord}.

cc #12517

[breaking-change]

Closes #12925

The Float trait in libstd is quite a large trait which has dependencies on cmath
(libm) and such, which libcore cannot satisfy. It also has many functions that
libcore can implement, however, as LLVM has intrinsics or they're just bit
twiddling.

This commit moves what it can of the Float trait from the standard library into
libcore to allow floats to be usable in the core library. The remaining
functions are now resident in a FloatMath trait in the standard library (in the
prelude now). Previous code which was generic over just the Float trait may now
need to be generic over the FloatMath trait.

[breaking-change]

This mostly involved frobbing imports between realstd, realcore, and the core
being test. Some of the imports are a little counterintuitive, but it mainly
focuses around libcore's types not implementing Show while libstd's types
implement Show.

This strips out all string-related functionality from the num module. The
inherited functionality is all that will be implemented in libcore (for now).
Primarily, libcore will not implement the Float trait or any string-related
functionality.

It may be possible to migrate string parsing functionality into libcore in the
future, but for now it will remain in libstd.

All functionality in core::num is reexported in std::num.