Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"No item found" diagnostic should suggest items that differ by case #86170

Closed
wesleywiser opened this issue Jun 9, 2021 · 4 comments · Fixed by #89956
Closed

"No item found" diagnostic should suggest items that differ by case #86170

wesleywiser opened this issue Jun 9, 2021 · 4 comments · Fixed by #89956
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@wesleywiser
Copy link
Member

Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a494a5e7386a6c9e55f7f39695dece41

enum Foo {
    Bar(u32)
}

fn main() {
    matches!(todo!(), Foo::BAR(_));
}

The current output is:

error[E0599]: no variant or associated item named `BAR` found for enum `Foo` in the current scope
 --> src/main.rs:6:28
  |
1 | enum Foo {
  | -------- variant or associated item `BAR` not found here
...
6 |     matches!(todo!(), Foo::BAR(_));
  |                            ^^^ variant or associated item not found in `Foo`

Ideally the output should include a note suggesting the variant with the same name (but different case):

error[E0599]: no variant or associated item named `BAR` found for enum `Foo` in the current scope
 --> src/main.rs:6:28
  |
1 | enum Foo {
  | -------- variant or associated item `BAR` not found here
...
6 |     matches!(todo!(), Foo::BAR(_));
  |                            ^^^ variant or associated item not found in `Foo`
  | help: a similarly named variant exists: `Bar`
@wesleywiser wesleywiser added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 9, 2021
@inquisitivecrystal
Copy link
Contributor

@rustbot label +C-enhancement +D-newcomer-roadblock

@rustbot rustbot added C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. labels Jun 9, 2021
@ben0x539
Copy link
Contributor

This only doesn't Just Work because the Levenshtein thing is case sensitive, right? There is some special-casing for case-insensitive suggestions but afaict it only applies if the case-sensitive Levenshtein distance is also already low, which seems wrong at first glance.

@ben0x539
Copy link
Contributor

ben0x539 commented Jun 16, 2021

im working on this
Edit: I'm not working on this anymore because I ran out of time getting past incremental compilation / llvm errors after a rebase.

@ben0x539
Copy link
Contributor

ben0x539 commented Jun 16, 2021

Okay, judging by

let input = vec![Symbol::intern("AAAA")];
// Returns None because `lev_distance > max_dist / 3`
assert_eq!(find_best_match_for_name(&input, Symbol::intern("aaaa"), None), None);
, this is explicitly not supposed to work. shrug emoji

Edit: Okay, maybe that test case didn't really care.

The use of case-insensitive match as tie breaker for equal levenshtein distance only was introduced with #46347 (comment) afaict.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 18, 2021
…match-names, r=estebank

Suggest a case insensitive match name regardless of levenshtein distance

Fixes rust-lang#86170

Currently, `find_best_match_for_name` only returns a case insensitive match name depending on a Levenshtein distance. It's a bit unfortunate that that hides some suggestions for typos like `Bar` -> `BAR`. That idea is from rust-lang#46347 (comment), but I think it still makes some sense to show a candidate when we find a case insensitive match name as it's more like a typo.
Skipped the `candidate != lookup` check because the current (i.e, `levenshtein_match`) returns the exact same `Symbol` anyway but it doesn't seem to confuse anything on UI tests.

r? `@estebank`
@bors bors closed this as completed in 8c8835d Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants