Remove duplicated `Flags` methods.
The `Flags` trait has two methods: `flags` and `outer_exclusive_binder`. Multiple types impl this trait and then also have duplicate inherent methods with the same names; these are all marked with "Think about removing this" comments. This is left over from things being moved into `rustc_type_ir`.
This commit removes those inherent methods. This requires adding `use Flags` to a number of files.
r? @lcnr
Remove some unnecessary lifetimes.
We have a number of structs with more lifetimes than necessary. This commit removes them.
LLM disclosure: I asked Claude Code to check for unnecessary lifetimes in all types with three or more lifetimes, and it produced a list of candidates (half of which were invalid). I did the modifications for the valid cases myself, and found a couple more cases along the way.
r? @JohnTitor
We have a number of structs with more lifetimes than necessary. This
commit removes them.
LLM disclosure: I asked Claude Code to check for unnecessary lifetimes
in all types with three or more lifetimes, and it produced a list of
candidates (half of which were invalid). I did the modifications for the
valid cases myself, and found a couple more cases along the way.
The `Flags` trait has two methods: `flags` and `outer_exclusive_binder`.
Multiple types impl this trait and then also have duplicate inherent
methods with the same names; these are all marked with "Think about
removing this" comments. This is left over from things being moved into
`rustc_type_ir`.
This commit removes those inherent methods. This requires adding `use
Flags` to a number of files.
Refactor FnDecl and FnSig non-type fields into a new wrapper type
#### Why this Refactor?
This PR is part of an initial cleanup for the [arg splat experiment](https://github.com/rust-lang/rust/issues/153629), but it's a useful refactor by itself.
It refactors the non-type fields of `FnDecl`, `FnSig`, and `FnHeader` into a new packed wrapper types, based on this comment in the `splat` experiment PR:
https://github.com/rust-lang/rust/pull/153697#discussion_r3004637413
It also refactors some common `FnSig` creation settings into their own methods. I did this instead of creating a struct with defaults.
#### Relationship to `splat` Experiment
I don't think we can use functional struct updates (`..default()`) to create `FnDecl` and `FnSig`, because we need the bit-packing for the `splat` experiment.
Bit-packing will avoid breaking "type is small" assertions for commonly used types when `splat` is added.
This PR packs these types:
- ExternAbi: enum + `unwind` variants (38) -> 6 bits
- ImplicitSelfKind: enum variants (5) -> 3 bits
- lifetime_elision_allowed, safety, c_variadic: bool -> 1 bit
#### Minor Changes
Fixes some typos, and applies rustfmt to clippy files that got skipped somehow.
Fix conflicting deref move suggestion for LazyLock patterns
fixesrust-lang/rust#154826.
Rust was suggesting *V -> V for let (v,) = *V, which then triggered a follow-up error suggesting the opposite. This patch makes that case suggest borrowing (&*V) instead. Also handles destructuring assignment separately so we don’t emit a misleading &*... fix-it there.
Fix ICE in borrowck mutability suggestion with multi-byte ref sigil
Fixesrust-lang/rust#139089
Similarly to rust-lang/rust#155068, this is another instance where span arithmetic did not account for multi-byte characters. (Note that the ampersand in the test is full-width)
This change also results in correcting some inappropriate suggestions.
Fix misleading "borrowed data escapes outside of function" diagnostic
Fixesrust-lang/rust#154350
Fall back to `report_general_error()` when `fr_name_and_span` is `None` in function items, since the "escaping data" framing is only appropriate for closures capturing outside variables.
changed the information provided by (mut x) to mut x (Fix 155030)
When trying to change a value without using mut in a for loop, the recommendation for this change is incorrect, so I am correcting it.
resolve: rust-lang/rust#155030
When a coroutine has too many parameters, `check_match` fails and
`construct_error` builds a MIR body with only the coroutine's computed
args (env + resume type). The user-provided signature, however, still
reflects all the parameters the user wrote. `check_signature_annotation`
then tries to `zip_eq` these two mismatched iterators, causing a panic.
Checking `tainted_by_errors` and bailing early avoids this, since
`construct_error` bodies cannot meaningfully be compared against user
annotations.
Add suggestion to `.to_owned()` used on `Cow` when borrowing
fixesrust-lang/rust#144792
supersedes rust-lang/rust#144925 with the review comments addressed
the tests suggested from @Kivooeo from https://github.com/rust-lang/rust/pull/144925#discussion_r2252703007 didn't work entirely, because these tests failed due to error `[E0308]` mismatched types, which actually already provides a suggestion, that actually makes the code compile:
```
$ cargo check
error[E0308]: mismatched types
--> src/main.rs:3:5
|
1 | fn test_cow_suggestion() -> String {
| ------ expected `std::string::String` because of return type
2 | let os_string = std::ffi::OsString::from("test");
3 | os_string.to_string_lossy().to_owned()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `String`, found `Cow<'_, str>`
|
= note: expected struct `std::string::String`
found enum `std::borrow::Cow<'_, str>`
help: try using a conversion method
|
3 | os_string.to_string_lossy().to_owned().to_string()
| ++++++++++++
```
now this suggestion is of course not good or efficient code, but via clippy with `-Wclippy::nursery` lint group you can actually get to the correct code, so i don't think this is too much of an issue:
<details>
<summary>the clippy suggestions</summary>
```
$ cargo clippy -- -Wclippy::nursery
warning: this `to_owned` call clones the `Cow<'_, str>` itself and does not cause its contents to become owned
--> src/main.rs:3:5
|
3 | os_string.to_string_lossy().to_owned().to_string()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#suspicious_to_owned
= note: `#[warn(clippy::suspicious_to_owned)]` on by default
help: depending on intent, either make the `Cow` an `Owned` variant
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ++
help: or clone the `Cow` itself
|
3 - os_string.to_string_lossy().to_owned().to_string()
3 + os_string.to_string_lossy().clone().to_string()
|
$ # apply first suggestion
$ cargo c -- -Wclippy::nursery
warning: redundant clone
--> src/main.rs:3:45
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ^^^^^^^^^^^^ help: remove this
|
note: this value is dropped without further use
--> src/main.rs:3:5
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#redundant_clone
= note: `-W clippy::redundant-clone` implied by `-W clippy::nursery`
= help: to override `-W clippy::nursery` add `#[allow(clippy::redundant_clone)]`
```
</details>
the actual error that we are looking for is error `[E0515]`, cannot return value referencing local variable, which was only present in the original issue due to automatic type inference assuming you want to return a cloned `Cow<'_, str>`, which is of course not possible. this is why i took the original test functions and turned them into closures, where it's less obvious that it's trying to return the wrong type.
r? davidtwco
(because you reviewed the last attempt)
(also, let me know if i should squash this down to one commit and add myself as the co-contributor)
`ty::Alias` refactor
This PR changes the following alias-related types from this:
```rust
pub enum AliasTyKind {
Projection,
Inherent,
Opaque,
Free,
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub def_id: I::DefId,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTyKind, AliasTy<I>),
}
```
Into this:
```rust
pub enum AliasTyKind<I: Interner> {
Projection { def_id: I::DefId },
Inherent { def_id: I::DefId },
Opaque { def_id: I::DefId },
Free { def_id: I::DefId },
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub kind: AliasTyKind<I>,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTy<I>),
}
```
... and then does a thousand other changes to accommodate for this change everywhere.
This brings us closer to being able to have `AliasTyKind`s which don't require a `DefId` (and thus can be more easily created, etc). Although notably we depend on both `AliasTyKind -> DefId` and `DefId -> AliasTyKind` conversions in a bunch of places still.
r? lcnr
----
A lot of these changes were done either by search & replace (via `ast-grep`) or on auto pilot, so I'm not quite sure I didn't mess up somewhere, but at least tests pass...
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#154554 (emit error on `#[track_caller]` with `extern fn`)
- rust-lang/rust#154858 (Change api of formatting diagnostic attribute strings.)
- rust-lang/rust#154876 (attr parsing: make sure we pass the right target when errors could be emitted)
borrowck: Don't mention unused vars in closure outlive errors
When there is a closure arg lifetime error, the code does its best to find variables that correspond to the lifetimes involved. This commit stops mentioning arguments that are unused in closures, since they are not relevant. This removes the "red herring" of rust-lang/rust#113121.
The `user_arg_index` nomenclature can be applied more broadly, but then the diff becomes annoyingly big, so I chose not to do that.
Review each commit individually for a nicer experience.
When there is a lifetime error, the code does its best to find variables
that correspond to the lifetimes involved. This commit stops mentioning
arguments that are unused in closures, since they are not relevant.
See the diff of the blessed test to get a good clue of what that means.
Introduce #[diagnostic::on_move(message)]
cc rust-lang/rust#149862
This is a first proposal. I have deliberately kept it simpler than `diagnostic::on_unimplemented`.
Few questions/remarks:
- Do I need to move the OnMoveDirective logic into a dedicated module perhaps ? let's say into compiler/rustc_borrowck/src/diagnostics/on_move.rs
- No problems to depend on crates like `rustc_ast` from the borrowck ?
- Notes are not supported yet. While message and label are very static , in the sense that they are emitted in the same way from the same place in the borrowck, it is not the case for the notes. It would make the code more complex. But, I can add support for notes if it does make sense.
Suggestions are welcomed !
Show named lifetime in closure upvar diagnostics
Fixesrust-lang/rust#153545.
When a closure captures a variable whose type involves a named lifetime from the parent function (e.g., `'a`), the borrow checker's region renumbering creates a separate `RegionVid` for each occurrence of the erased lifetime in the closure's upvar type. These new `RegionVid`s have no `external_name`, so diagnostics fall back to synthetic names like `'1`.
This PR recovers the original lifetime name by matching the closure's upvar type against the parent function's parameter type (obtained via `liberate_late_bound_regions`). Both types have the same structure but different region representations, the parent has `ReLateParam`/`ReEarlyParam` with real names, the closure has `ReVar` from renumbering. Walking them in parallel with `for_each_free_region` lets us find which named lifetime corresponds to the anonymous `RegionVid`.
Before:
```rust
error[E0716]: temporary value dropped while borrowed
--> test.rs:11:21
|
6 | fn apply<'a>(
| -- lifetime `'1` defined here
```
After:
```rust
error[E0716]: temporary value dropped while borrowed
--> test.rs:11:21
|
6 | fn apply<'a>(
| -- lifetime `'a` defined here
```
The fix gracefully falls back to the existing `'1` naming when it can't match, nested closures, local variables (not parameters), destructuring patterns, or partial captures where the type structures diverge.
mejrs
