Suggest importable type that differs only in capitalization

[dtolnay]

struct S {
    m: Hashmap<String, ()>,
}

error[E0412]: cannot find type `Hashmap` in this scope
 --> src/main.rs:2:8
  |
2 |     m: Hashmap<String, ()>,
  |        ^^^^^^^ not found in this scope

If the code had been written with HashMap instead of Hashmap, we would get the following extremely likely correct suggestion:

error[E0412]: cannot find type `HashMap` in this scope
 --> src/main.rs:2:8
  |
2 |     m: HashMap<String, ()>,
  |        ^^^^^^^ not found in this scope
  |
help: consider importing one of these items
  |
1 | use std::collections::HashMap;
  |
1 | use std::collections::hash_map::HashMap;
  |

Hashmap is a fairly common capitalization in other languages (https://grep.app/search?q=Hashmap&case=true) so it would be good to provide an appropriate suggestion in this case.

(For whatever reason this doesn't trigger #72640.)

[chrissimpkins]

@rustbot claim

[chrissimpkins]

Here is where I am with the error message and suggestion in a case-insensitive match:

error[E0412]: cannot find type `Hashmap` in this scope
 --> src/lib.rs:2:8
  |
2 |     m: Hashmap<String, ()>,
  |        ^^^^^^^ not found in this scope
  |
help: did you mean `std::collections::HashMap`?
  |
2 |     m: std::collections::HashMap<String, ()>,
  |        ^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

Thoughts about broadening to more libstd types? IIUC, under the conditions: (1) not explicitly brought into scope; (2) not defined in the Rust prelude; (3) not a primitive type, misspelled std lib types result in the "not found in this scope" message with no suggestion.

[chrissimpkins]

#72988

[estebank]

For whatever reason this doesn't trigger #72640.

We explicitly keep track of whether we are looking at a path's generics in field currently_processing_generics and only suggest adding a new type param then that is the case. I believe my original thinking was that the likelihood of it being a reasonable suggestion increased in that case. Also, looking at the diff for the original PR introducing this there are cases like type Output = Option<Foo>;, where if we triggered for type Output = Foo; we would be suggesting type Output<Foo> = Foo; which is nonsensical. If by experience you feel we should suggest in the case of struct S(Foo);, then I can change this.

I think I've addressed this aside in a reasonable way in #73320: