Fix resolution of local items that shadow imported ones

[ironcev]

Description

Closes #5383.

#5383 blocks PR #5306.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[jjcnn]

This definitely fixes a bug, but there's still an issue when the imported declaration is used before the local declaration:

use lib::Enum;

pub const Y: Enum = Enum::A;

enum Enum {
    A: (),
    B: (),
}

The type Enum in the declaration of Y resolves to the locally defined type rather than the imported one.

It's probably intentional that type declarations are in scope in the entire file, but I was surprised to see it resolve this way, so maybe it's worth it to issue a warning when a used type name has multiple resolutions?

In any case the scope of type declarations is unclear from the documentation.

[ironcev]

This definitely fixes a bug, but there's still an issue when the imported declaration is used before the local declaration

This is actually expected behavior. Items follow item-style shadowing and not sequential shadowing. They are visible in the whole module no matter where they are declared. E.g.:

fn first() {
   second();
}

fn second() {
   let _ = Enum::A;
}

enum Enum {
    A: (),
}

Which means Enum is visible everywhere and thus shadows the imported one everywhere.

In the above example we will also get an error for the name clash, but the resolution should still be to the local one, because the shadowing is not sequential but item-style.

To item-style shadowing and sequential shadowing, I like the explanation/definitions given in the Rust RFC 116 (No module shadowing).

[jjcnn]

To item-style shadowing and sequential shadowing, I like the explanation/definitions given in the Rust RFC 116 (No module shadowing).

"Due to a certain lack of official, clearly defined semantics and terminology, ..."

Suffice it to say I don't. :-)

[ironcev]

Suffice it to say I don't. :-)

Well, as long as we don't have anything better... 😄