Suggest crate keyword when unresolved path contains current crate's name

[joculatrix]

Related to #138312.

Unsure about the second "help" message suggested by the issue writer, but for at least the main part of the issue, I've added a check to emit a suggestion replacing the current crate's name in a path with crate. Let me know if there's a more elegant way to do this.

[rustbot]

r? @estebank

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

[apiraino]

r? compiler

[fee1-dead]

r? compiler

[jieyouxu]

Thanks for the PR. However, I'm hesitant about making this suggestion at all because of potential for a lot of incorrect/misleading suggestions, even if the suggestion is MaybeIncorrect (as in, I'm hesitant about the signal-to-noise ratio).

Some examples:

• There might be modules in other places of various visibilities that shares the same name as the root crate name, and it's not clear to me that the root crate is necessarily frequently the right answer.
• It's not clear to me that just because the current crate name happens to be the same as the unresolved module/linked crate, that it is the right suggestion. It is possible that even though the root crate name is foo, you can still have an extern crate of the same name! E.g. you can provide an extern crate candidate via rustc foo.rs --extern foo=libbar.rlib, and extern crate foo; and use foo::{...} in foo.rs root module would not be "itself".

[jieyouxu]

Problem: I don't think this is right. Counter-example:

// foo.rs
mod bar {
    pub fn baz() {}
}

use crate::foo::baz;

fn main() {}

error[E0432]: unresolved import `crate::foo`
 --> foo.rs:5:12
  |
5 | use crate::foo::baz;
  |            ^^^ use of unresolved module or unlinked crate `foo`
  |
help: the current crate name can not be used in a path, use the keyword `crate` instead
  |
5 - use crate::foo::baz;
5 + use crate::crate::baz;
  |

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0432`.

[jieyouxu]

Problem: I think this condition is too lax. Even if we constrain this suggestion to only be made if

1. Unresolved module/crate is the first path segment of a non-1-length path
2. Not a global path, e.g. ::foo

I think the possibility of false positives is still quite high, even if the applicability is MaybeIncorrect.

[joculatrix]

Thanks for the review! I definitely agree with your comments. In light of your hesitancy about trying to add the suggestion at all, should I go ahead and close the PR?

[jieyouxu]

Yeah, I think for now we should close this PR. I'd be open to revisiting some heuristic that'd provide a higher signal-to-noise ratio, but I can't immediately think of a combination right now. Thanks for the exploration anyway!