Remove support for `extern "rust-intrinsic"` blocks
Part of rust-lang/rust#132735
Looked manageable and there didn't appear to have been progress in the last two weeks,
so decided to give it a try.
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).
The `max_line_length` property was set to 100 for all filetypes, which
led to git commit messages being wrapped at 100 characters instead of
the usual 75. This introduces an exception for the special file used by
git to write commit messages.
Signed-off-by: Prajwal S N <prajwalnadig21@gmail.com>
A new syntax node `ast::VariantDef` has been introduced to map between the HIR node and the AST.
The files have been updated with `cargo test -p xtask`.
Signed-off-by: Prajwal S N <prajwalnadig21@gmail.com>
Specifically, when a rename of a local will change some code that refers it to refer another local, or some code that refer another local to refer to it.
We do it by introducing a dummy edit with an annotation. I'm not a fond of this approach, but I don't think LSP has a better way.
This is required to format evaluated consts, because we need trait env, and it needs the crate (currently it uses the last crate in topological order, which is wrong, the next commit will fix that).
