Update docs on Error struct. #29355
This adds a pretty contrived example of the usage of fmt::Error. I am
very open to suggestions for a better one.
I have also highlighted the fmt::Error vs std::error::Error.
r? @steveklabnik
This adds a pretty contrived example of the usage of fmt::Error. I am
very open to suggestions for a better one.
I have also highlighted the fmt::Error vs std::error::Error.
r? @steveklabnik
Implement Eq/Hash/Debug etc. for unsized tuples.
As I mentioned in [the comment in #18469](https://github.com/rust-lang/rust/issues/18469#issuecomment-306767422), the implementations of `PartialEq`, `Eq`, `PartialOrd`, `Ord`, `Debug`, `Hash` can be generalized to unsized tuples.
This is consistent with the `derive` behavior for unsized structs.
```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Debug, Default, Hash)]
struct MyTuple<X, Y, Z: ?Sized>(X, Y, Z);
fn f(x: &MyTuple<i32, i32, [i32]>) {
x == x;
x < x;
println!("{:?}", x);
}
```
Questions:
- Need an RFC?
- Need a feature gate? I don't think it does because the unsized tuple coercion #42527 is feature-gated.
- I changed `builder.field($name);` into `builder.field(&$name);` in the `Debug` implementation to pass compilation. This won't affect the behavior because `Debug for &'a T` is a mere redirection to `Debug for T`. However, I don't know if it affects code size / performance.
Update docs for Debug* structs. #29355
This adds docs for the Debug* structs as well as examples from the
Formatter::debug_* methods, so that a user knows how to construct them.
I added these examples as the builders module is not public and hence
the debug_*_new() functions are not available to a user.
r? @steveklabnik
This adds docs for the Debug* structs as well as examples from the
Formatter::debug_* methods, so that a user knows how to construct them.
I added these examples as the builders module is not public and hence
the debug_*_new() functions are not available to a user.
r? @steveklabnik
Review comments.
Mainly adding in the links for all of the structs and functions.
Remove rust tag on code blocks.
I reworded it slightly to make it more clear that the function only take
two arguments - the output and the Arguments struct that can be
generated from the format_args! macro.
r? @steveklabnik
The documentation for flt2dec doesn't match up with the actual
implementation, so fix the documentation to align with reality.
Presumably due to the mismatch, the formatting code for floats in
std::fmt can use correspondingly shorter arrays in some places, so fix
those places up as well.
Fixes#41304.
The comments for flt2dec::to_shortest_str says that we only need a slice
of length 5 for the parts array. Initializing a 16-part array is just
wasted effort and wasted stack space. Other functions in the flt2dec
module have similar comments, so we adjust the parts arrays passed to
those functions accordingly.
For the two major entry points for float formatting, we split the exact
case and the shortest cases into separate functions. We mark the
separate functions as #[inline(never) so the exact cases won't bloat
stack space in their callers unnecessarily. The shortest cases are
marked so for similar reasons.
Fixes#41234.
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`.
:06 :<06 :>06 :^06
before |-001.2| |-1.200| |-001.2| |-01.20|
after |-001.2| |-001.2| |-001.2| |-001.2|
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.
:05 :<05 :>05 :^05
before |-0001| |-1000| |-0001| |-0100|
after |-0001| |-0001| |-0001| |-0001|
:#05x :<#05x :>#05x :^#05x
before |0x001| |0x100| |000x1| |0x010|
after |0x001| |0x001| |0x001| |0x001|
Fixes#39997 [breaking-change]
Bump version, upgrade bootstrap
This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.
This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.
This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which
understands and supports 128-bit integers throughout.
The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to
iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported,
this strategy is good enough to get past the first bootstrap stages to end up with a fully working
128-bit capable compiler.
In order for this strategy to work, number of locations had to be changed to use associated
max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?)
had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works
(former not necessarily producing the right results in stage1).
This commit includes manual merge conflict resolution changes from a rebase by @est31.
Removes the `STATUSES` static which duplicates truth from the pattern
match in `collect_lang_features`.
Fixes existing duplicates by renaming:
- never_type{,_impls} on `impl`s on `!`
- concat_idents{,_macro} on `macro_rules! concat_idents`
Fixes#37013.
feat: reinterpret `precision` field for strings
This commit changes the behavior of formatting string arguments with both width and precision fields set.
Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space.
This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored.
For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected:
```python
>>> '{:/^10.8}'.format('1234567890')
'/12345678/'
```
This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char.
__However, this is the breaking change, I admit.__ Feel free to close it, but otherwise it should be mentioned in the `std::fmt` documentation somewhere near of `fill/align/width` fields description.
This commit changes the behavior of formatting string arguments
with both width and precision fields set.
Documentation says that the `width` field is the "minimum width"
that the format should take up. If the value's string does not
fill up this many characters, then the padding specified by
fill/alignment will be used to take up the required space.
This is true for all formatted types except string, which is truncated
down to `precision` number of chars and then all of `fill`, `align` and
`width` fields are completely ignored.
For example: `format!("{:/^10.8}", "1234567890);` emits "12345678".
In the contrast Python version works as the expected:
```python
>>> '{:/^10.8}'.format('1234567890')
'/12345678/'
```
This commit gives back the `Python` behavior by changing the `precision`
field meaning to the truncation and nothing more. The result string *will*
be prepended/appended up to the `width` field with the proper `fill` char.
However, this is the breaking change.
Also updated `std::fmt` docs about string precision.
Signed-off-by: Evgeny Safronov <division494@gmail.com>
This is a spiritual succesor to #34268/8531d581, in which we replaced a
number of matches of None to the unit value with `if let` conditionals
where it was judged that this made for clearer/simpler code (as would be
recommended by Manishearth/rust-clippy's `single_match` lint). The same
rationale applies to matches of None to the empty block.
