Suggest importing for partial mod path matching in name resolving

[chenyukang]

Fixes #112590

[rustbot]

r? @wesleywiser

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

This suggestion isn't great, since it doesn't take into account the fact that the path may have additional segments that don't make sense after the suggestion is applied.

[chenyukang]

This message is not introduced by this PR, but from here:

rust/compiler/rustc_resolve/src/diagnostics.rs

Line 1506 in 04075b3

"{} {} with a similar name exists",

The output is:

RUST_BACKTRACE=1 rustc +dev2 --edition 2021 tests/ui/macros/builtin-prelude-no-accidents.rs
error[E0433]: failed to resolve: use of undeclared crate or module `vec`
 --> tests/ui/macros/builtin-prelude-no-accidents.rs:7:14
  |
7 |     type B = vec::Vec<u8>; //~ ERROR use of undeclared crate or module `vec`
  |              ^^^
  |              |
  |              use of undeclared crate or module `vec`
  |              help: a struct with a similar name exists (notice the capitalization): `Vec`

error: aborting due to previous error

I guess the diagnostic emitter did some formatting stuff, if there are multiple diagnostics in the same place, it will display in list items?

We might fix this suggestion in another PR.

[estebank]

I agree this is pre-existing and can be done separately. It can be dealt by making smart_resolve_report_errors pass in the whole path (and a len: usize arg to signal the path segment that failed) and doing multiple try_lookup_name_relaxed and try to select the right candidates. I would assume that the last path segment is always the most critical to bias towards when searching for the right candidate.

[estebank]

It seems the only thing left would be to check in the above suggestion if the suggested type has an associated item corresponding to the next path segment (in order to avoid suggesting things like Vec::Vec when we know that Vec doesn't have anything named Vec within it.

I think we can do that as a separate PR.

[compiler-errors]

This isn't that useful either 🤔

[chenyukang]

There is a difference between 2015 edition and later edition,

With this PR, the output for 2021 edition is:

rustc +dev2 --edition 2021 tests/ui/resolve/export-fully-qualified.rs
error[E0432]: unresolved import `foo`
 --> tests/ui/resolve/export-fully-qualified.rs:7:13
  |
7 |         use foo;
  |             ^^^ no external crate `foo`
  |
help: consider importing this module instead
  |
7 |         use crate::foo;
  |  

the testing framework is running without 2021, so it's suggesting to write this:

mod foo {
    pub fn bar() {
        use foo;
        foo::baz();
    } //~ ERROR failed to resolve: use of undeclared crate or module `foo`

    fn baz() { }
}

This is valid code for 2015 edition. If we compile with a new edition we will suggest using crate:

~/rust ❯❯❯ rustc +dev2 --edition 2018 tests/ui/resolve/export-fully-qualified.rs
error[E0432]: unresolved import `foo`
 --> tests/ui/resolve/export-fully-qualified.rs:7:13
  |
7 |         use foo;
  |             ^^^ no external crate `foo`
  |
help: consider importing this module instead
  |
7 |         use crate::foo;
  |             ~~~~~~~~~~

error: aborting due to previous error

Maybe it's related to this issue #112924

Anyway, this suggestion seems right for different versions.

Or it's better to suggest writing like this?

crate::foo::baz();

[estebank]

We should have two tests, one for 2015 and one for 2018, so that we can ensure that the suggestions keep being reasonable for both :)

[chenyukang]

yes, added another test tests/ui/resolve/export-fully-qualified-2018.rs.

[estebank]

@bors r+

[bors]

📌 Commit b26701e has been approved by estebank

It is now in the queue for this repository.

[bors]

⌛ Testing commit b26701e with merge e728b5b...

[bors]

☀️ Test successful - checks-actions
Approved by: estebank
Pushing e728b5b to master...

[rust-timer]

Finished benchmarking commit (e728b5b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 669.062s -> 670.726s (0.25%)