Use (😏) precise capture instead of Captures trait hack

[yotamofek]

No description provided.

[rustbot]

r? @GuillaumeGomez

rustbot has assigned @GuillaumeGomez.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

Some changes occurred in exhaustiveness checking

cc @Nadrieril

[Urgau]

r? compiler

[GuillaumeGomez]

At least looks good to me. :)

[Zalathar]

Many of the functions that currently use Captures would not need any use<> markers at all under the 2024 edition capture rules.

For that reason, even though we have use<> today, I think it’s better to delay some or all of this cleanup until after upgrading to Rust 2024. Until then, the hack serves as a de-facto marker of functions that need to be reexamined after the edition bump.

Whereas if we do this now, we either lose that easily-greppable information from the source, or we’re just replacing one perfectly-functional hack with a bunch of noisy TODOs to revisit later.

[lqd]

For the compiler side, I think the plan was to move to edition 2024 with its different capture rules instead of what this PR proposes.

[yotamofek]

Many of the functions that currently use Captures would not need any use<> markers at all under the 2024 edition capture rules.

For that reason, even though we have use<> today, I think it’s better to delay some or all of this cleanup until after upgrading to Rust 2024. Until then, the hack serves as a de-facto marker of functions that need to be reexamined after the edition bump.

Whereas if we do this now, we either lose that easily-greppable information from the source, or we’re just replacing one perfectly-functional hack with a bunch of noisy TODOs to revisit later.

Waiting for the 2024 edition sounds like a better plan then, thank you for taking the time to explain. So should I close this?

BTW, are there any plans for a lint that'll point out removable use<>s in Rust 2024?

[compiler-errors]

Yea, I'd prefer if we close this.

I've got a PR (#129636) open to upgrade the compiler to edition 2024, but I'm waiting for the edition to be stable so that we can upgrade all of the crates that currently rust-analyzer shares with rustc, rather than having to hold them back separately.

I've implemented a lint for redundant captures in the IMPL_TRAIT_REDUNDANT_CAPTURES lint, which will fire in edition 2024. I've noticed that I don't think I ever got signoff on making that lint warn, so I'll probably make sure T-lang is okay with that, lool.