Skip to content

Too many errors for missing crate for nested imports and later uses of crate #153156

@estebank

Description

@estebank

Code

use foo::{bar, baz::bat};
pub fn main() {
    foo::qux();
}

Current output

error[E0433]: cannot find module or crate `foo` in this scope
 --> src/main.rs:1:5
  |
1 | use foo::{bar, baz::bat};
  |     ^^^ use of unresolved module or unlinked crate `foo`
  |
  = help: if you wanted to use a crate named `foo`, use `cargo add foo` to add it to your `Cargo.toml`

error[E0432]: unresolved import `foo`
 --> src/main.rs:1:5
  |
1 | use foo::{bar, baz::bat};
  |     ^^^ use of unresolved module or unlinked crate `foo`
  |
  = help: if you wanted to use a crate named `foo`, use `cargo add foo` to add it to your `Cargo.toml`

error[E0433]: cannot find module or crate `foo` in this scope
 --> src/main.rs:3:5
  |
3 |     foo::qux();
  |     ^^^ use of unresolved module or unlinked crate `foo`
  |
  = help: if you wanted to use a crate named `foo`, use `cargo add foo` to add it to your `Cargo.toml`

Desired output

error[E0432]: unresolved import `foo`
 --> src/main.rs:1:5
  |
1 | use foo::{bar, baz::bat};
  |     ^^^ use of unresolved module or unlinked crate `foo`
  |
  = help: if you wanted to use a crate named `foo`, use `cargo add foo` to add it to your `Cargo.toml`

Rationale and extra context

Either one of the first two errors would be fine, both at the same time are redundant.

The third error is more acceptable, but ideally we wouldn't emit it. Potentially, it might make sense to have a single error pointing at line 1 and line 3, but we can "just" silence the third error after the prior import error (like we already do if we write use foo;). This would make it so that a fixing a typo in the import would then suddenly trigger later errors in places where the typo also needed to be fixed, but that should be ok.

Other cases

Rust Version

1.93 and 1.95 nightly

Anything else?

No response

Metadata

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsD-verboseDiagnostics: Too much output caused by a single piece of incorrect code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions