| Age | Commit message (Collapse) | Author | Lines |
|
[unstable, deprecated since 1.11.0]
|
|
|
|
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]
|
|
|
|
|
|
|
|
|
|
* Move to a separate float mod
* Add more tests for f64 f32 lower exp upper exp
* Use assert_eq for a clearer error message
|
|
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.
|
|
|
|
|
|
|
|
just as ceil(log10(2^64)) == 20
|
|
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.
|
|
|
|
Because we handle artifically-constructed references to it in live code which
is a totally broken thing to do.
|
|
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.
|
|
|
|
Update to new macro url syntax
r? @steveklabnik
|
|
return a slice
They panic if the buffer is too small.
|
|
Add missing Eq implementations
Part of #36301.
|
|
|
|
|
|
|
|
|
|
|
|
Split Ty::is_empty method into is_never and is_uninhabited
|
|
Mainly, remove mk_empty() method and replace with tcx.types.empty
|
|
|
|
|
|
|
|
3Hren:issue/xx/reinterpret-format-precision-for-strings, r=alexcrichton
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.
|
|
This makes it clearer that we're not just looking for a lower bound but
rather know that the iterator is an `ExactSizeIterator`.
|
|
Support 16-bit pointers as well as i/usize
I'm opening this pull request to get some feedback from the community.
Although Rust doesn't support any platforms with a native 16-bit pointer at the moment, the [AVR-Rust][ar] fork is working towards that goal. Keeping this forked logic up-to-date with the changes in master has been onerous so I'd like to merge these changes so that they get carried along when refactoring happens. I do not believe this should increase the maintenance burden.
This is based on the original work of Dylan McKay (@dylanmckay).
[ar]: https://github.com/avr-rust/rust
|
|
|
|
This is based on the original work of Dylan McKay for the
[avr-rust project][ar].
[ar]: https://github.com/avr-rust/rust
|
|
|
|
Remove unused trait imports
|
|
Also add `Hash` to `std::cmp::Ordering` and most possible traits to
`fmt::Error`.
|
|
|
|
Automated conversion using the untry tool [1] and the following command:
```
$ find -name '*.rs' -type f | xargs untry
```
at the root of the Rust repo.
[1]: https://github.com/japaric/untry
|
|
Currently these have non-traditional APIs which take a buffer and report how
much was filled in, but they're not necessarily ergonomic to use. Returning an
iterator which *also* exposes an underlying slice shouldn't result in any
performance loss as it's just a lazy version of the same implementation, and
it's also much more ergonomic!
cc #27784
|
|
|
|
Removes all unstable and deprecated APIs prior to the 1.8 release. All APIs that
are deprecated in the 1.8 release are sticking around for the rest of this
cycle.
Some notable changes are:
* The `dynamic_lib` module was moved into `rustc_back` as the compiler still
relies on a few bits and pieces.
* The `DebugTuple` formatter now special-cases an empty struct name with only
one field to append a trailing comma.
|
|
This is actually a reexported implementation detail in the `rt::v1` module but
rustdoc doesn't like reexporting items from `doc(hidden)` modules. Do what we'd
end up doing anyway from an API perspective and make a public-facing `enum` that
can be retranslated under the hood if necessary.
|
|
Fixes #9447
|