Warn if a top-level definition shadows an imported one

[arielherself]

This PR hopefully resolves #4519. A new warning will be shown like this:

warning: Definition of "foo" shadows an imported value
  ┌─ /src/warning/wrn.gleam:3:4
  │
3 │ fn foo(x) {
  │    ^^^

The imported value could not be used in functions anyway.

However, I found a similar issue for constructors and type aliases. Especially if we import a constructor and define a type (not constructor) with the same name, the imported item will be used:

import module1.{Bar}  // imported Bar is a constructor

type Bar {  // local Bar is a type
}

pub fn main() {
	Bar  // this resolves to module1.Bar
}

Is this an intended behavior? If not I think we should add an error for this.

[GearsDatapacks]

The latter is intended behaviour. Types and values live in different namespaces

[arielherself]

I see. I have updated the warning message and changelog.

[arielherself]

I also updated the test result of this existing test:

#[test]
fn used_shadowed_imported_value() {
    assert_warning!(
        (
            "thepackage",
            "wibble",
            "
pub const wibble = 1
"
        ),
        "
import wibble.{wibble}

pub const wibble = wibble
"
    );
}

Since redefining values is not actually legal, there should be a warning on shadowing of wibble here even if we used the imported wibble explicitly. Correct me if I'm wrong!

[lpil]

That one should not warn 🙏 Until #614 is resolved it has valid uses.

[arielherself]

Thanks for your clarification! I've added logic to not complain about direct re-exports like const c = c.

[lpil]

Thank you!

I've actually realised I was wrong with my previous guidance, the programmer should in that case use the qualified syntax. Sorry, I was quite tired when I wrote it! Could you remove that exception please 🙏

[lpil]

Please move the code for this check into the existing definition analysis rather than iterating over the functions and constants again 🙏

[arielherself]

Of course! 💜