Handle conflicting import of items declared in the same module

[mukilan]

Fixes #19498

[emberian]

Could you add a test for this?

[nrc]

Is this missing some cases - sorry to be vague, but it seems like you are only catching reflexive loops, but any loop could cause this issue (is that right?)

[mukilan]

@nick29581 : I assume you are talking about cases like this (the below one is a simple loop, while we can have arbitrary length cycles)

mod A {
   pub use B::submodule;  // error: unresolved import B::submodule;
}

mod B {
   pub use A::submodule; // error: unresolved import A::submodule;
}

fn main() {
}

In such cases, the fixed point algorithm will terminate because no progress will be made in resolving any of the import directive, and an error will be printed for each import.

[mukilan]

@nick29581 : I think now I understand your concern. The existing logic takes care of case like this.

mod A {

   use self::B::C::B;  //  error: import `B` conflicts with existing submodule

   mod B {   //  note: note conflicting module here
       mod C {
            mod B {}
       }
   }
}


fn main() {
}

[mukilan]

@cmr: I mainly submitted this PR for feedback on the approach I have taken. This PR fixes the issue for the Single Import case, while Globs still give the same "unresolved import" error, which I haven't yet looked into.

Do you think my current approach is fine (i.e globs will be handled within resolve_glob_import) or should I think about doing the check at a higher level (perhaps here).

FWIW, although I can't confirm it yet, I believe even if we moved the check to a higher level, we need to perform the same kinds of checks performed in the individual functions if the error message needs to be something like "type/value/module x conflicts y". However if the error message is generic like "can't import from the same module", without listing specific conflicts, we can just do the check and bailout at the higher level.

EDIT: cc'ing @nick29581