Rustc suggests the same use statement that caused the error when two modules share their name

[CastilloDel]

Code

I tried to reproduce the problem in the playground

mod a {
    pub mod log {
        pub struct S {}
    }
}

use a::log::{self};

use log::SetLoggerError;

fn main() {}

Current output

The output for the playground code is the following:

error[E0432]: unresolved import `log::SetLoggerError`
  --> src/main.rs:12:5
   |
12 | use log::SetLoggerError;
   |     ^^^^^^^^^^^^^^^^^^^ no `SetLoggerError` in `a::log`
   |
help: consider importing this struct instead
   |
12 | use log::SetLoggerError;
   |     ~~~~~~~~~~~~~~~~~~~

The one I actually saw:

 unresolved import `proto::LogLevelValue`
 --> tests/tests/server_api.rs:3:5
  |
3 | use proto::LogLevelValue;
  |     ^^^^^^^^^^^^^^^^^^^^ no `LogLevelValue` in `proto`
  |
help: consider importing this enum instead
  |
3 | use proto::LogLevelValue;
  |     ~~~~~~~~~~~~~~~~~~~~

The second one is worse, because "no LogLevelValue in proto" doesn't indicate that this proto comes is a different proto than the one in the suggestion. I think this happens because the modules aren't in the same file or crate, so I couldn't reproduce it in the playground.

Desired output

Ideally, rustc should be able to notify the user that the error comes from the fact that there are two modules with the same name, instead of suggesting the same code as a fix.

Rationale and extra context

rustc 1.73.0 (cc66ad468 2023-10-03)

Other cases

No response

Anything else?

Sorry if this is duplicated, but I couldn't find an issue regarding this problem

[fmease]

MCVE:

// === dep.rs ===   rustc dep.rs --crate-type=lib
pub struct SomeUsefulType;

// === usr.rs ===   rustc usr.rs --edition=2021 --extern=dep=libdep.rlib
mod dep {}
use dep::SomeUsefulType;

fn main() {}

error[E0432]: unresolved import `dep::SomeUsefulType`
 --> usr.rs:2:5
  |
2 | use dep::SomeUsefulType;
  |     ^^^^^^^^^^^^^^^^^^^ no `SomeUsefulType` in `dep`
  |
help: consider importing this struct instead
  |
2 | use dep::SomeUsefulType;
  |     ~~~~~~~~~~~~~~~~~~~

Explanation: The suggestion doesn't account for the case where a local module (here dep) has the same name as the crate found in the external prelude that contains the wanted item. If this situation arises, it should instead suggest:

help: consider importing this struct instead
  |
2 | use ::dep::SomeUsefulType;
  |     ~~~~~~~~~~~~~~~~~~~~~