Fix unused_variables typo suggestions for const patterns

[onehr]

Closes #147595

This fixes unused_variables typo suggestions that could print replacement
patterns which are not valid from the binding site.

The fix keeps the existing def_path_str output when it is already valid, but
adjusts two local-item cases:

• items outside the binding module are printed with crate::...;
• items nested inside the current body are printed relative to that body.

It also suppresses const typo suggestions for bare let x = ... bindings,
because replacing the binding with a const path creates a refutable pattern.
Unit ADT typo suggestions are left unchanged.

The regression test covers 2015 and 2021 editions, cross-module consts,
same-module consts, function-local consts, cross-module variants, and bare
let const initializers.

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

r? @mejrs

rustbot has assigned @mejrs.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 18 candidates

[mejrs]

Thanks!

• Please add a regression test for not suggesting path::_, like reported in the issue.
• Please add explicit HELP annotations in the new tests.

It looks good otherwise but I'm not familiar enough here to tell whether or not corner cases are being missed, so

r? @fmease or @estebank

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[onehr]

Thanks @mejrs for your comments, resolved.

[onehr]

@rustbot ready

[apiraino]

Visiting during triage.

@onehr when you have a chance, feel free to rebase.
@cjgillot / @fmease for another look.

@rustbot author

thanks

[onehr]

@apiraino rebased, thank you for reminding me!

[fmease]

Unfortunately, this approach doesn't fully cut it.

Consider for example:

pub fn veiled() { pub const X: i32 = 1; }

pub fn demo(x: Option<i32>) {
    let Some(x) = x else { return };
}

where your code suggests crate::veiled::X for x which doesn't resolve since veiled is not a module but a function. def_path_str doesn't care about that as it happily generates pseudo paths which is totally legitimate for it to do, btw.

It's interesting that is_accessible_from doesn't account for that (maybe it shouldn't). Of course, rustc@main is equally incorrect as it suggests veiled::X.

Haven't thought about potential solutions to this yet...

View changes since the review

[fmease]

Furthermore, with_crate_prefix!(…def_path_str…) renders the "principal path" but we would need it to be relative to the current scope since the path might not be accessible here.

Consider:

mod mod1 {
    mod mod0 { pub const X: i32 = 1; }
    pub use mod0::X;
}

pub fn demo(x: Option<i32>) {
    let Some(x) = x else { return };
}

Here, you suggest crate::mod1::mod0::X (and main suggests mod1::mod0::X) which isn't accessible inside demo. I'm not sure if we have infra / an API in the compiler that would allow us to find the path if available (here: crate::mod1::X / mod1::X). We probably don't since I figure that can get very complicated very quickly if the re-exports are more complex...

So I'd say let's "just" disqualify this candidate. Clearly is_accessible_from isn't the right check since it follows re-exports it seems. Unclear if there's a method somewhere that would help us out here...

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.