Fixes#24173
These docs could all use examples, so for now, let's just remove the bad one, and when I go over this whole module I'll put in better ones.
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
This is an implementation of [RFC 1030][rfc] which adds these traits to the
prelude and additionally removes all inherent `into_iter` methods on collections
in favor of the trait implementation (which is now accessible by default).
[rfc]: https://github.com/rust-lang/rfcs/pull/1030
This is technically a breaking change due to the prelude additions and removal
of inherent methods, but it is expected that essentially no code breaks in
practice.
[breaking-change]
Closes#24538
Add conditional overflow-checking to signed negate operator.
I argue this can land independently of #24420 , because one can write the implementation of `wrapped_neg()` inline if necessary (as illustrated in two cases on this PR).
This needs to go into beta channel.
Fix Debug impl for RangeFull
The Debug impl was using quotes, which was inconsistent:
=> (.., 1.., 2..3, ..4)
(\"..\", 1.., 2..3, ..4)
Fix to use just ..
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
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.
