Add some clarifications and fixes for fmt syntax
This tries to clarify a few things regarding fmt syntax:
- The comment on `Parser::word` seems to be wrong, as that underscore-prefixed words are just fine. This was changed in https://github.com/rust-lang/rust/pull/66847.
- I struggled to follow the description of the width argument. It referred to a "second argument", but I don't know what second argument it is referring to (which is the first?). Either way, I rewrote the paragraph to try to be a little more explicit, and to use shorter sentences.
- The description of the precision argument wasn't really clear about the distinction of an Nth argument and a named argument. I added a sentence to try to emphasize the difference.
- `IDENTIFIER_OR_KEYWORD` was changed recently in https://github.com/rust-lang/reference/pull/2049 to include bare `_`. But fmt named arguments are not allowed to be a bare `_`.
This tries to clarify a few things regarding fmt syntax:
- The comment on `Parser::word` seems to be wrong, as that
underscore-prefixed words are just fine. This was changed in
https://github.com/rust-lang/rust/pull/66847.
- I struggled to follow the description of the width argument. It
referred to a "second argument", but I don't know what second argument
it is referring to (which is the first?). Either way, I rewrote the
paragraph to try to be a little more explicit, and to use shorter
sentences.
- The description of the precision argument wasn't really clear about
the distinction of an Nth argument and a named argument. I added
a sentence to try to emphasize the difference.
- `IDENTIFIER_OR_KEYWORD` was changed recently in
https://github.com/rust-lang/reference/pull/2049 to include bare `_`.
But fmt named arguments are not allowed to be a bare `_`.
Detect Python-style numeric grouping syntax in format strings (e.g. `{x:,}`)
and emit a clear diagnostic explaining that it is not supported in Rust.
This helps users coming from Python understand the error without exposing
the full set of valid Rust format specifiers.
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
rustc_parse_format: improve error for missing `:` before `?` in format args
Detect the `{ident?}` pattern where `?` is immediately followed by `}` and emit a clearer diagnostic explaining that `:` is required for Debug formatting. This avoids falling back to a generic “invalid format string” error and adds a targeted UI test for the case.
Detect the `{ident?}` pattern where `?` is immediately followed by `}` and emit
a clearer diagnostic explaining that `:` is required for Debug formatting.
This avoids falling back to a generic “invalid format string” error and adds
a targeted UI test for the case.
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
Fix format string grammar in docs and improve alignment error message for #144023
This PR improves error messages and documentation for format strings involving alignment and formatting traits.
Highlights:
- Clearer error messages for invalid alignment specifiers (e.g., `{0:#X>18}`), showing the expected `<`, `^`, or `>` and a working example:
println!("{0:>#18X}", value);
- Updated UI test `format-alignment-hash.rs` to reflect the improved error output.
- Documentation clarification: ensures examples correctly show how width, alignment, and traits like `x`, `X`, `#` combine.
Motivation:
Previously, using `#` with alignment and width produced confusing errors. This PR guides users on the correct syntax and provides actionable examples.
Testing:
- Built the compiler (`./x build`)
- Blessed and ran UI tests (`./x. test src/test/ui/fmt/format-alignment-hash.rs --bless`)
- Verified full test suite passes (`./x test`)
Issue: rust-lang/rust#144023
It's very useful. There are some false positives involving integration
tests in `rustc_pattern_analysis` and `rustc_serialize`. There is also a
false positive involving `rustc_driver_impl`'s
`rustc_randomized_layouts` feature. And I removed a `rustc_span` mention
in a doc comment in `rustc_log` because it wasn't integral to the
comment but caused a dev-dependency.
Reduce formatting `width` and `precision` to 16 bits
This is part of https://github.com/rust-lang/rust/issues/99012
This is reduces the `width` and `precision` fields in format strings to 16 bits. They are currently full `usize`s, but it's a bit nonsensical that we need to support the case where someone wants to pad their value to eighteen quintillion spaces and/or have eighteen quintillion digits of precision.
By reducing these fields to 16 bit, we can reduce `FormattingOptions` to 64 bits (see https://github.com/rust-lang/rust/pull/136974) and improve the in memory representation of `format_args!()`. (See additional context below.)
This also fixes a bug where the width or precision is silently truncated when cross-compiling to a target with a smaller `usize`. By reducing the width and precision fields to the minimum guaranteed size of `usize`, 16 bits, this bug is eliminated.
This is a breaking change, but affects almost no existing code.
---
Details of this change:
There are three ways to set a width or precision today:
1. Directly a formatting string, e.g. `println!("{a:1234}")`
2. Indirectly in a formatting string, e.g. `println!("{a:width$}", width=1234)`
3. Through the unstable `FormattingOptions::width` method.
This PR:
- Adds a compiler error for 1. (`println!("{a:9999999}")` no longer compiles and gives a clear error.)
- Adds a runtime check for 2. (`println!("{a:width$}, width=9999999)` will panic.)
- Changes the signatures of the (unstable) `FormattingOptions::[get_]width` methods to use a `u16` instead.
---
Additional context for improving `FormattingOptions` and `fmt::Arguments`:
All the formatting flags and options are currently:
- The `+` flag (1 bit)
- The `-` flag (1 bit)
- The `#` flag (1 bit)
- The `0` flag (1 bit)
- The `x?` flag (1 bit)
- The `X?` flag (1 bit)
- The alignment (2 bits)
- The fill character (21 bits)
- Whether a width is specified (1 bit)
- Whether a precision is specified (1 bit)
- If used, the width (a full usize)
- If used, the precision (a full usize)
Everything except the last two can simply fit in a `u32` (those add up to 31 bits in total).
If we can accept a max width and precision of u16::MAX, we can make a `FormattingOptions` that is exactly 64 bits in size; the same size as a thin reference on most platforms.
If, additionally, we also limit the number of formatting arguments, we can also reduce the size of `fmt::Arguments` (that is, of a `format_args!()` expression).
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to
consider options that avoids breaking downstream usages of cargo on
distributed `rustc-src` artifacts, where such cargo invocations fail due
to inability to inherit `lints` from workspace root manifest's
`workspace.lints` (this is only valid for the source rust-lang/rust
workspace, but not really the distributed `rustc-src` artifacts).
This breakage was reported in
<https://github.com/rust-lang/rust/issues/138304>.
This reverts commit 48caf81484, reversing
changes made to c6662879b2.
By naming them in `[workspace.lints.rust]` in the top-level
`Cargo.toml`, and then making all `compiler/` crates inherit them with
`[lints] workspace = true`. (I omitted `rustc_codegen_{cranelift,gcc}`,
because they're a bit different.)
The advantages of this over the current approach:
- It uses a standard Cargo feature, rather than special handling in
bootstrap. So, easier to understand, and less likely to get
accidentally broken in the future.
- It works for proc macro crates.
It's a shame it doesn't work for rustc-specific lints, as the comments
explain.
