I found that the current description of `enumerate()` doesn't actually tell you what, specifically, the method does, and you have to look at the example to figure it out. Here's a description that I think is better.
The link works on the `std/ptr/index.html` docs page, but not the `std/primitive.pointer.html` page. Instead of leaving it half-broken, it is removed.
I tried fixing this in #24432, but @alexcrichton mentioned that this doc string was used in two places (with different base paths unfortunately).
r? @alexcrichton
Fixes#20596 by making `Debug` render negative zero with a `-` without affecting the behavior of `Display`.
While I was at it, I also removed some dead code from `float_to_str_bytes_common` (the one from `libcore/fmt/float.rs`, not the function of the same name in `libstd/num/strconv.rs`). It had support for different bases, and for negative numbers, but the function is internal to core and the couple places that call it (all in `libcore/fmt/mod.rs`) never use those features: They pass in `num.abs()` and base 10.
The meaning of each variant of this enum was somewhat ambiguous and it's uncler
that we wouldn't even want to add more enumeration values in the future. As a
result this error has been altered to instead become an opaque structure.
Learning about the "first invalid byte index" is still an unstable feature, but
the type itself is now stable.
Since it doesn't utilize the parameter, it's not very idiomatic since it
could just use the `Result::or` method. So this changes the example to
utilize the parameter. As far as I can tell, all the numbers in this
example are completely arbitrary.
`wrapping_div`, `wrapping_rem`, `wrapping_neg`,
`wrapping_shl`, `wrapping_shr`.
All marked unstable under `core` feature for now (with expectation of
being marked as stable by 1.0 release).
There are syntax extensions that call `std::rt::begin_unwind` passing it a `usize`. I updated the syntax extension to instead pass `u32`, but for bootstrapping reasons, I needed to create a `#[cfg(stage0)]` version of `std::rt::begin_unwind` and therefore also `panic!`.
Arguments, Formatters, and the various format traits remain stable. The
format_args! macro uses #[allow_internal_unstable] to allow it access to
the unstable things in core::fmt.
Destabilized things include a "v1" in their name:
* core::fmt::rt
* core::fmt::rt::v1 (the module and all contents)
* core::fmt::ArgumentV1
* core::fmt::ArgumentV1::new
* core::fmt::ArgumentV1::from_usize
* core::fmt::Arguments::new_v1
* core::fmt::Arguments::new_v1_formatted
The unstable message was copied from that of std::io::_print.
From [here](http://doc.rust-lang.org/nightly/std/primitive.i8.html):
> `fn rotate_right(self, n: u32) -> i8`
> Shifts the bits to the right by a specified __amount amount__, n, wrapping the truncated bits to the beginning of the resulting integer.
This fixes the bug described in issue #23150. This affected formatting any floating point number into a string in a formatting pattern that: a) required rounding up, and b) required an extra digit on the front.
So `format!(\"{:.0}\", 9.9)` would fail, but `format!(\"{:.0}\", 8.9)` would succeed. This was due to a negative integer being cast to a `usize` resulting in an 'arithmetic operation overflowed' panic.
The fix was to change the order of operations so that the number is zero before casting.
Use `discriminant_value` intrinsic for `derive(PartialOrd)`
[breaking-change]
This is a [breaking-change] because it can change the result of comparison operators when enum discriminants have been explicitly assigned. Notably in a case like:
```rust
#[derive(PartialOrd)]
enum E { A = 2, B = 1}
```
Under the old deriving, `A < B` held, because `A` came before `B` in the order of declaration. But now we use the ordering according to the provided values, and thus `A > B`. (However, this change is very unlikely to break much, if any, code, since the orderings themselves should all remain well-defined, total, etc.)
Fix#15523
The meaning of each variant of this enum was somewhat ambiguous and it's uncler
that we wouldn't even want to add more enumeration values in the future. As a
result this error has been altered to instead become an opaque structure.
Learning about the "first invalid byte index" is still an unstable feature, but
the type itself is now stable.
This commit series starts out with more official test harness support for rustdoc tests, and then each commit afterwards adds a test (where appropriate). Each commit should also test and finish independently of all others (they're all pretty separable).
I've uploaded a [copy of the documentation](http://people.mozilla.org/~acrichton/doc/std/) generated after all these commits were applied, and a double check on issues being closed would be greatly appreciated! I'll also browse the docs a bit and make sure nothing regressed too horribly.
Implements an intrinsic for extracting the value of the discriminant
enum variant values. For non-enum types, this returns zero, otherwise it
returns the value we use for discriminant comparisons. This means that
enum types that do not have a discriminant will also work in this
arrangement.
This is (at least part of) the work on Issue #24263
The main change in this patch is removing the use of `Option` inside the
inner loops of those functions to avoid comparisons where one branch
will only trigger on the first pass through the loop.
The included benchmarks go from:
test bench_max ... bench: 372 ns/iter (+/- 118)
test bench_max_by ... bench: 428 ns/iter (+/- 33)
test bench_max_by2 ... bench: 7128 ns/iter (+/- 326)
to:
test bench_max ... bench: 317 ns/iter (+/- 64)
test bench_max_by ... bench: 356 ns/iter (+/- 270)
test bench_max_by2 ... bench: 1387 ns/iter (+/- 183)
Problem noticed in http://www.reddit.com/r/rust/comments/31syce/using_iterators_to_find_the_index_of_the_min_or/
The main change in this patch is removing the use of `Option` inside the
inner loops of those functions to avoid comparisons where one branch
will only trigger on the first pass through the loop.
The included benchmarks go from:
test bench_max ... bench: 372 ns/iter (+/- 118)
test bench_max_by ... bench: 428 ns/iter (+/- 33)
test bench_max_by2 ... bench: 7128 ns/iter (+/- 326)
to:
test bench_max ... bench: 317 ns/iter (+/- 64)
test bench_max_by ... bench: 356 ns/iter (+/- 270)
test bench_max_by2 ... bench: 1387 ns/iter (+/- 183)
Problem noticed in http://www.reddit.com/r/rust/comments/31syce/using_iterators_to_find_the_index_of_the_min_or/
bors