| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
https://www.reddit.com/r/rust/comments/3ceaui/psa_produces_prettyprinted_debug_output/
|
|
Each formatting trait now has an example of implementation, as well as a
fuller description of what it's supposed to output.
It also contains a link to the module-level documentation which
Fixes #25765
|
|
This recently regressed in #24689, and this updates the `Display` implementation
to take formatting flags into account.
Closes #26625
|
|
This recently regressed in #24689, and this updates the `Display` implementation
to take formatting flags into account.
Closes #26625
|
|
|
|
|
|
This commit shards the broad `core` feature of the libcore library into finer
grained features. This split groups together similar APIs and enables tracking
each API separately, giving a better sense of where each feature is within the
stabilization process.
A few minor APIs were deprecated along the way:
* Iterator::reverse_in_place
* marker::NoCopy
|
|
`FormatError` is not exist anymore.
|
|
|
|
This is the logical next step after #24661, but I’m less sure about this one.
|
|
|
|
|
|
|
|
|
|
[breaking-change]
|
|
As a side effect `core::fmt::float` is gone now. This also slightly
changes the float output, so this is:
[breaking-change]
|
|
This + DST coercions (#24619) would allow code like `Rc<RefCell<Box<Trait>>>` to
be simplified to `Rc<RefCell<Trait>>`.
|
|
|
|
Conflicts:
src/libcore/result.rs
|
|
This commit removes all the old casting/generic traits from `std::num` that are
no longer in use by the standard library. This additionally removes the old
`strconv` module which has not seen much use in quite a long time. All generic
functionality has been supplanted with traits in the `num` crate and the
`strconv` module is supplanted with the [rust-strconv crate][rust-strconv].
[rust-strconv]: https://github.com/lifthrasiir/rust-strconv
This is a breaking change due to the removal of these deprecated crates, and the
alternative crates are listed above.
[breaking-change]
|
|
|
|
|
|
as accepted in [RFC 526](https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md).
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Conflicts:
src/test/compile-fail/coherence-impls-copy.rs
|
|
|
|
|
|
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes #22985
Closes #21069
[breaking-change]
r? @alexcrichton
|
|
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes #22985
Closes #21069
[breaking-change]
|
|
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
The affected functions are:
* ptr::copy
* ptr::copy_nonoverlapping
* slice::bytes::copy_memory
* intrinsics::copy
* intrinsics::copy_nonoverlapping
Closes #22890
[breaking-change]
|
|
The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
[breaking-change]
|
|
|
|
|
|
All methods are inlined into Iterator with `Self: Sized` bounds to make
sure Iterator is still object safe.
[breaking-change]
|
|
Also convert [T]'s Debug impl. The behavior of the alternate flag here's
changing.
|
|
The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
[breaking-change]
|
|
Conflicts:
src/librustc/middle/ty.rs
src/librustc_trans/trans/adt.rs
src/librustc_typeck/check/mod.rs
src/libserialize/json.rs
src/test/run-pass/spawn-fn.rs
|
|
|
|
Now that support has been removed, all lingering use cases are renamed.
|
|
|
|
This permits all coercions to be performed in casts, but adds lints to warn in those cases.
Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference.
[breaking change]
* Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed.
* The unused casts lint has gone.
* Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are:
- You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_`
- Casts do not influence inference of integer types. E.g., the following used to type check:
```
let x = 42;
let y = &x as *const u32;
```
Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information:
```
let x: u32 = 42;
let y = &x as *const u32;
```
|
|
|
