Indents for `cbox` and `ibox` are 0 or `INDENT_UNIT` (4) except for a
couple of places which are `INDENT_UNIT - 1` for no clear reason.
This commit changes the three space indents to four spaces.
Rollup of 9 pull requests
Successful merges:
- #134446 (Stabilize the `cell_update` feature)
- #139307 (std: Add performance warnings to HashMap::get_disjoint_mut)
- #139450 (Impl new API `std::os::unix::fs::mkfifo` under feature `unix_fifo`)
- #139809 (Don't warn about `v128` in wasm ABI transition)
- #139852 (StableMIR: Implement `CompilerInterface`)
- #139945 (Extend HIR to track the source and syntax of a lifetime)
- #140028 (`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns)
- #140181 (Remove `synstructure::Structure::underscore_const` calls.)
- #140232 (Remove unnecessary clones)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `synstructure::Structure::underscore_const` calls.
The `synstructure` docs say "This method is a no-op, underscore consts are used by default now." The behaviour change occurred going from `synstructure` version 0.13.0 to 0.13.1.
r? ``@SparrowLii``
`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns
When `deref_patterns` is enabled, this allows string literal patterns to be used where `str` is expected and byte string literal patterns to be used where `[u8]` or `[u8; N]` is expected. This lets them be used in explicit `deref!("...")` patterns to match on `String`, `Box<str>`, `Vec<u8>`, `Box<[u8;N]>`, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on #138992: similar to how byte string literals matching on `&[u8]` is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call `<str as PartialEq>::eq` in the MIR lowering for string equality tests).
This PR does not add support for implicit deref pattern syntax (e.g. `"..."` matching on `String`, as `string_deref_patterns` allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1].
This also does not add support for using named or associated constants of type `&str` where `str` is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals.
This is gated by the `deref_patterns` feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes.
The update to the unstable book added by this will conflict with #140022, so they shouldn't be merged at the same time.
Tracking issue for deref patterns: #87121
r? ``@oli-obk``
cc ``@Nadrieril``
[^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see #44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by `deref_patterns`). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.
Extend HIR to track the source and syntax of a lifetime
An upcoming lint will want to be able to know if a lifetime is hidden (e.g. `&u8`, `ContainsLifetime`) or anonymous: (e.g. `&'_ u8`, `ContainsLifetime<'_>`). It will also want to know if the lifetime is related to a reference (`&u8`) or a path (`ContainsLifetime`).
r? ``@nnethercote``
StableMIR: Implement `CompilerInterface`
This PR implements part of [the document](https://hackmd.io/``@celinaval/H1lJBGse0).``
With `TablesWrapper` wrapped by `CompilerInterface`, the stable-mir's TLV stores a pointer to `CompilerInterface`, while the rustc-specific TLV stores a pointer to tables.
transmute: Mark edges by byte sets, not byte values
This leads to drastic performance improvements. For example, on the author's 2024 MacBook Pro, the time to convert the `Tree` representation of a `u64` to its equivalent DFA representation drops from ~8.5ms to ~1us, a reduction of ~8,500x. See `bench_dfa_from_tree`.
Similarly, the time to execute a transmutability query from `u64` to `u64` drops from ~35us to ~1.7us, a reduction of ~20x. See `bench_transmute`.
r? `@jswrenn`
Pass `args` to `run` instead of storing it in a field. This avoids the
need to clone it within `run`.
Also, change `args` from `Vec<String>` to `&[String]`, avoiding the need
for some vecs and clones.
I found these by grepping for `&[a-z_\.]*\.clone()`, i.e. expressions
like `&a.b.clone()`, which are sometimes unnecessary clones, and also
looking at clones nearby to cases like that.
make abi_unsupported_vector_types a hard error
Fixes https://github.com/rust-lang/rust/issues/116558 by completing the transition; see that issue for context. The lint was introduced with Rust 1.84 and this has been shown in cargo's future breakage reports since Rust 1.85, released 6 weeks ago, and so far we got 0 complaints by users. There's not even a backlink on the tracking issue. We did a [crater run](https://github.com/rust-lang/rust/pull/127731#issuecomment-2286736295) when the lint was originally added and found no breakage. So I don't think we need another crater run now, but I can do one if the team prefers that.
https://github.com/rust-lang/rust/issues/131800 is done, so for most current targets (in particular, all tier 1 and tier 2 targets) we have the information to implement this check (modulo the targets where we don't properly support SIMD vectors yet, see the sub-issues of https://github.com/rust-lang/rust/issues/116558). If a new target gets added in the future, it will default to reject all SIMD vector types until proper information is added, which is the default we want.
This will need approval by for `@rust-lang/lang.` Cc `@workingjubilee` `@veluca93`
try-job: test-various
try-job: armhf-gnu
try-job: dist-i586-gnu-i586-i686-musl
An upcoming lint will want to be able to know if a lifetime is
hidden (e.g. `&u8`, `ContainsLifetime`) or anonymous: (e.g. `&'_ u8`,
`ContainsLifetime<'_>`). It will also want to know if the lifetime is
related to a reference (`&u8`) or a path (`ContainsLifetime`).
In the `Tree` and `Dfa` representations of a type's layout, store byte
ranges rather than needing to separately store each byte value. This
permits us to, for example, represent a `u8` using a single 0..=255 edge
in the DFA rather than using 256 separate edges.
This leads to drastic performance improvements. For example, on the
author's 2024 MacBook Pro, the time to convert the `Tree` representation
of a `u64` to its equivalent DFA representation drops from ~8.5ms to
~1us, a reduction of ~8,500x. See `bench_dfa_from_tree`.
Similarly, the time to execute a transmutability query from `u64` to
`u64` drops from ~35us to ~1.7us, a reduction of ~20x. See
`bench_transmute`.
The `synstructure` docs say "This method is a no-op, underscore consts
are used by default now." The behaviour change occurred going from
`synstructure` version 0.13.0 to 0.13.1.
`rc""` more clear error message
here is small fix that provides better error message when user is trying to use `rc""` the same way it was made for `rb""`
example of it's work
```rust
|
2 | rc"\n";
| ^^ unknown prefix
|
= note: prefixed identifiers and literals are reserved since Rust 2021
help: use `cr` for a raw C-string
|
2 - rc"\n";
2 + cr"\n";
|
```
**related issue**
fixes#140170
cc `@cyrgani` (issue author)
Use `is_lang_item` and `as_lang_item` instead of handrolling their logic
Various cleanups and deduplication. Most notably `if is_lang_item(foo, bar) {} else if is_lang_item...` chains are turned into matches. No behaviour changes intended beyond turning ICEs into fatal "lang item not found" errors
Clean: rename `open_braces` to `open_delimiters` in lexer and move `make_unclosed_delims_error` into `diagnostics.rs`.
Clean code prepared for resolving #138401. To avoid having too many extraneous changes in one PR, I cleaned up some of the naming and method placement in lexer in this PR.
1. For the make_unclosed_delims_error function defined in mod.rs is only used in lexer, so moved into lexer, which enhances encapsulation.
2. For open_braces in TokenTreeDiagInfo the naming is not canonical, as Brace refers to `{...} ` and this variable can store all kinds of different Delimiters. so I named it open_delimiters.
r? `@chenyukang`
Handle another negated literal in `eat_token_lit`.
Extends the change from #139653, which was on expressions, to literals.
Fixes#140098.
r? ``@petrochenkov``
improve diagnostic for raw pointer field access with ->
This PR enhances the error messages emitted by the Rust compiler when users attempt to use the `->` operator for field access on raw pointers or when dereferencing is needed. The changes aim to provide clearer guidance, by suggesting the correct use of the `.` operator and explicit dereferencing.
**Before:**
```
help: `xs` is a raw pointer; try dereferencing it
|
LL | (*xs)->count += 1;
| ++ +
```
**Now:**
```
help: use `.` on a dereferenced raw pointer instead
|
LL - xs->count += 1;
LL + (*xs).count += 1;
|
```
I added extra clarification in the message. Since this error occurs in the parser, we can't be certain that the type is a raw pointer. That's why the message includes only a small note in brackets. (In contrast, the message above is emitted in HIR, where we *can* check whether it's a raw pointer.)
**Before:**
```
--> main.rs:11:11
|
11 | xs->count += 1;
| ^^
|
= help: the . operator will dereference the value if needed
```
**After:**
```
--> main.rs:11:11
|
11 | xs->count += 1;
| ^^
|
= help: the `.` operator will automatically dereference the value, except if the value is a raw pointer
```
Improve diagnostics for pointer arithmetic += and -= (fixes#137391)
**Description**:
This PR improves the diagnostic message for cases where a binary assignment operation like `ptr += offset` or `ptr -= offset` is attempted on `*mut T`. These operations are not allowed, and the compiler previously suggested calling `.add()` or `.wrapping_add()`, which is misleading if not assigned.
This PR updates the diagnostics to suggest assigning the result of `.wrapping_add()` or `.wrapping_sub()` back to the pointer, e.g.:
**Examples**
For this code
```rust
let mut arr = [0u8; 10];
let mut ptr = arr.as_mut_ptr();
ptr += 2;
```
it will say:
```rust
10 | ptr += 2;
| ---^^^^^
| |
| cannot use `+=` on type `*mut u8`
|
help: consider replacing `ptr += offset` with `ptr = ptr.wrapping_add(offset)` or `ptr.add(offset)`
|
10 - ptr += 2;
10 + ptr = ptr.wrapping_add(2);
```
**Related issue**: #137391
cc `@nabijaczleweli` for context (issue author)
Construct OutputType using macro and print [=FILENAME] help info
Closes#139805
Use define_output_types to define variants of OutputType, as well as refactor all of its methods for clarity. This way no variant is missed when pattern matching or output help messages.
On top of that, I optimized for `emit` help messages.
r? ```@jieyouxu```
Remove `token::{Open,Close}Delim`
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`.
PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by
replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless
variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing
with delimiters. It also makes `ast::TokenKind` more similar to
`parser::TokenType`.
This requires a few new methods:
- `TokenKind::is_{,open_,close_}delim()` replace various kinds of
pattern matches.
- `Delimiter::as_{open,close}_token_kind` are used to convert
`Delimiter` values to `TokenKind`.
Despite these additions, it's a net reduction in lines of code. This is
because e.g. `token::OpenParen` is so much shorter than
`token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms
reduce to single line forms. And many places where the number of lines
doesn't change are still easier to read, just because the names are
shorter, e.g.:
```
- } else if self.token != token::CloseDelim(Delimiter::Brace) {
+ } else if self.token != token::CloseBrace {
```
r? `@petrochenkov`
