Suggest case insensitive import suggestions

[GTimothy]

View all comments

This PR proposes case insensitive import suggestions.
Previous discussion of this topic here: #72641 and in this PR: #72988
If that is still of interest, a discussion may be needed to limit or expand the included list.
I initially followed the suggestions in #72988.

The tests are based on the tests by @chrissimpkins in #72988.

I added a is_exact_match field to ImportSuggestion to modify the suggestion text accordingly.

Only when no other suggestion is made, do I check for case insensitive import suggestion.

fn test_layout(_x: LayOut){}
//~^ ERROR: cannot find type `LayOut` in this scope

error[E0425]: cannot find type `LayOut` in this scope
  --> $DIR/libstd.rs:3:20
   |
LL | fn test_layout(_x: LayOut){}
   |                    ^^^^^^ not found in this scope
   |
help: consider importing this similarly named struct
   |
LL + use std::alloc::Layout;
   |

for a more complex case:
SystemTime exists in the stdlib, but I only suggest case insensitive import when nothing else is suggested

fn test_systemtime(_x: Systemtime){}
//~^ ERROR: cannot find type `Systemtime` in this scope

struct SystemTome{}
mod st{
    struct SystemTame{}
}

error[E0425]: cannot find type `Systemtime` in this scope
  --> $DIR/libstd.rs:428:24
   |
LL | fn test_systemtime(_x: Systemtime){}
   |                        ^^^^^^^^^^
...
LL | struct SystemTome{}
   | ----------------- similarly named struct `SystemTome` defined here
   |
help: a struct with a similar name exists
   |
LL - fn test_systemtime(_x: Systemtime){}
LL + fn test_systemtime(_x: SystemTome){}
   |

During this PR, I ended up adding two other things which could arguably be two separate PRs:

• filtering out typos suggestions that do not have parameters when the typo has some
  motivation: It suggested Clone (no parameter) for the std cloned<(),()> test when I expected Cloned<(),()> to be suggested.

• when suggesting that a missing binding is available in a pattern but not used because behind a .., suggest a MaybeIncorrect fix.
  motivation: this way, I can avoid looking for imports if there is a suggestion.

• custom import message for case insensitive suggestion.

• only suggest case insensitive when no other suggestion is made

• check for enum variant match before suggesting an enum

• check for enum variant parameter requirement before suggesting an enum

• check with reviewers where to place the test, and whether to rename them

• separate PRs for:

  • filtering out typos suggestions
  • a missing binding

• Let's keep this PR only related to case-insensitive import suggestions.

• squash the commits to three commits, easier to review

  • Adding tests and make a snapshot of current compiler behavior
  • The new implementation
  • Bless tests

[GTimothy]

I see from the 247 failed tests that 1-edit difference is too big for small names. 'net' should probably NOT be suggested to replace 'new'...

Edit: i have now switched to case insensitive match only.

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
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 17 candidates

[GTimothy]

upstream change #157991 contains commit cd2d10a and 4f6a600 from #157974 which do some weird file swapping instead of renamings that completely confuses and breaks my rebase attempts.
I may have some skill issue here, does anyone know how to fix this? Is there a proper git workflow to resolve this or do I need to copy my changes over to the swapped file and delete the changes in the original file by hand?

If this is not a skill issue on my part, maybe avoiding this kind of file swapping and splitting this in multiple rename commits would help git not getting confused ?

[GTimothy]

For anyone having trouble with the file swap, my cleanest solution is:

• assuming I have 7 commits on top of my out of date branch.
• assuming no existing *.patch files present.

# make patches out of my commits
git format-patch HEAD~7..HEAD

# edit the patch files to change the file path
sed -i 's|a/compiler/rustc_resolve/src/diagnostics.rs|a/compiler/rustc_resolve/src/error_helper.rs|g; s|b/compiler/rustc_resolve/src/diagnostics.rs|b/compiler/rustc
_resolve/src/error_helper.rs|g' *.patch  

# create new 'fix-swapped-files' branch from upstream latest
git checkout -b fix-swapped-files <upstream>/main

# apply updated patches
git am --committer-date-is-author-date *.patch 

[apiraino]

@rustbot reroll

[mu001999]

During this PR, I ended up adding two other things which could arguably be two separate PRs

I think it would be good to extract them as separate PRs. Let's keep this PR only related to case-insensitive import suggestions.

And, please squash the commits to three commits, which would be helpful to review:

1. Adding tests and make a snapshot of current compiler behavior
2. The new implementation
3. Bless tests

@rustbot author

View changes since this review

[rustbot]

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

[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.

[GTimothy]

During this PR, I ended up adding two other things which could arguably be two separate PRs

I think it would be good to extract them as separate PRs. Let's keep this PR only related to case-insensitive import suggestions.

Done, I extracted them as #161180 and #161182

And, please squash the commits to three commits, which would be helpful to review:

1. Adding tests and make a snapshot of current compiler behavior

2. The new implementation

3. Bless tests

Done :)

@rustbot ready