suggestion for typoed crate or module

[TaKO8Ki]

Previously, the compiler didn't suggest similarly named crates or modules. This pull request adds a suggestion for typoed crates or modules.

#76208

before:

error[E0433]: failed to resolve: use of undeclared type or module `chono`
 --> src/main.rs:2:5
  |
2 | use chono::prelude::*;
  |     ^^^^^ use of undeclared type or module `chono`

after:

error[E0433]: failed to resolve: use of undeclared type or module `chono`
 --> src/main.rs:2:5
  |
2 | use chono::prelude::*;
  |     ^^^^^ 
  |     |
  |     use of undeclared crate or module `chono`
  |     help: a similar crate or module exists: `chrono`

[rust-highfive]

r? @wesleywiser

(rust-highfive has picked a reviewer for you, use r? to override)

[TaKO8Ki]

@wesleywiser
Only test/ui/hygiene/extern-prelude-from-opaque-fail.rs failed. Could you give me some advice to solve this problem?

What I want to solve is:

In Zulip

In test/ui/hygiene/extern-prelude-from-opaque-fail.rs, a decl_macro a declares extern crate core as my_core internally and my_core::mem::drop(0) is called in a f() function outside the decl_macro. So my_core::mem::drop(0) causes a failed to resolve error, but the compiler suggests a similar crate name like the following which the function cannot use.

error[E0433]: failed to resolve: use of undeclared crate or module `my_core`
  --> $DIR/extern-prelude-from-opaque-fail.rs:24:14
   |
LL |     fn f() { my_core::mem::drop(0); }
   |              ^^^^^^^
   |              |
   |              use of undeclared crate or module `my_core`
   |              help: a similar crate or module exists: `my_core`

[TaKO8Ki]

r? @estebank

[wesleywiser]

I think to fully solve that issue, you'll need to do something very similar to what the identifier resolution does and traverse the scope to see what modules are currently in scope (see https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_resolve/lib.rs.html#1729-1740 which is probably what you need to call). That seems very messy though.

@estebank do you know of a better way?

[estebank]

@wesleywiser I think that you are right that that is the "principled" approach, but I think we should land this PR as is as a stopgap (without closing the original report so we can clean this up later). What do you think?

[wesleywiser]

Oh, yes absolutely! This seems like an obvious improvement over the status quo even if there are some edge cases.

[TaKO8Ki]

@estebank @wesleywiser Thank you for your advice!

[TaKO8Ki]

@estebank So should I open a new issue about that?

[estebank]

So should I open a new issue about that?

Please do.

[estebank]

Suggested change

	String::from("a similar crate or module exists"),
	String::from("there is a crate or module with a similar name"),

Ideally we would get the type of what the ident is from find_similarly_named_module_or_crate so we can be more specific in the message. We can do that later.

[TaKO8Ki]

Ok. I'll do it in a new PR.

[TaKO8Ki]

@estebank I opened a issue about that! #89592

[estebank]

There are three tests that are failing with the same ICE:

------------------------------------------
stderr:
------------------------------------------
thread 'rustc' panicked at '`ModuleData::def_id` is called on a block module', compiler/rustc_resolve/src/lib.rs:607:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.57.0-nightly (86650600b 2021-10-06) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z threads=1 -Z ui-testing -Z deduplicate-diagnostics=no -Z emit-future-incompat-report -Z save-analysis -C codegen-units=1 -C prefer-dynamic -C rpath -C debuginfo=0

query stack during panic:
end of query stack

------------------------------------------



failures:
    [ui] ui/proc-macro/weird-hygiene.rs
    [ui] ui/save-analysis/issue-59134-0.rs
    [ui] ui/save-analysis/issue-59134-1.rs

This can likely be prevented by looking at the module kind before calling def_id() or using opt_def_id() instead.

[petrochenkov]

I think that you are right that that is the "principled" approach, but I think we should land this PR as is as a stopgap

I understand this when we are talking about high-priority bugfixes, but with diagnostics this approach already turned rustc_parser into a nuclear garbage dump.

[TaKO8Ki]

@estebank @petrochenkov
Then, should I solve this problem in this PR?

[estebank]

If this is a temporary state of affairs, I'm ok landing this as is.

@petrochenkov The "principled" approach will complicate resolve and be potentially more intrusive compared to what is being put forward here. It is the principled approach because it is more thorough. The changes here are relegated into the diagnostics module and a single method call.

@TaKO8Ki can you please commit to follow up on this soon?

@bors r+

[bors]

📌 Commit f0a611b6b08397f41505fc0085e11f8cb0943fe6 has been approved by estebank

[Mark-Simulacrum]

Could we squash commits first, please? There's a few typo fixes and similar that seem like they would be nice to squash away. @bors r-

[TaKO8Ki]

@estebank

can you please commit to follow up on this soon?

Yes.

[estebank]

@bors r+

[bors]

📌 Commit f819e6d has been approved by estebank