This calculates the width and height using the bounding box of the window in the buffer. Bounding box coordinates are inclusive so I have to add 1 to both dimensions.
As per https://github.com/rust-lang/rust/issues/20405. To be more precise, the changes just the processing of enums when the name is "RUST$ENCODED$ENUM$..." so it correctly parses when there is more than one number encoding the location of the field it's looking for to determine state of the enum
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Part of #20013
[breaking-change]
This warning has been around in the compiler for quite some time now, but the
real place for a warning like this, if it should exist, is in Cargo, not in the
compiler itself. It's a first-class feature of Cargo that multiple versions of a
crate can be compiled into the same executable, and we shouldn't be warning
about our first-class features.
This warning has been around in the compiler for quite some time now, but the
real place for a warning like this, if it should exist, is in Cargo, not in the
compiler itself. It's a first-class feature of Cargo that multiple versions of a
crate can be compiled into the same executable, and we shouldn't be warning
about our first-class features.
cc #19260
Open questions:
- I still feel weird about marking functions like `exp` as `#[stable]` in `core` since they're highly likely to call into libm which is theoretically something core is designed to avoid and so we may be forced/want to move it at some point in the future, and so it feels like a lie to call it `#[stable]` (I know `core` is `#[experimental]`, but still...)
- `abs_sub` is a horrible name IMO: it feels like it is `(a - b).abs()`, but it is actually `(a - b).max(0.)`. maybe something along the lines of `pos_diff` ("positive difference") is better.
- the associated-function nature of `Int::from_be` and `Int::from_le` feel strange to me, it feels like they should be methods, but I cannot think of a good name.
I'm also not hugely in favour of `ldexp` and `frexp` but the precedent from C is large. (e.g. AFAICT, `ldexp` must mean "load exponent" which is essentially what it does... but only for a subset of its inputs.)
`FloatMath` no longer exists and all functionality from both traits is
available under `Float`. Change from
use std::num::{Float, FloatMath};
to
use std::num::Float;
[breaking-change]
These aren't in their final form, but are all aiming to be part of 1.0, so at the very least encouraging usage now to find the bugs is nice.
Also, the widespread roll-out of associated types in the standard library indicates they're getting good, and it's lame to have to activate a feature in essentially every crate ever.
