Shadowing when aliasing a type with the same name

[miniBill]

Proposed fix:

-- (fix) NoModuleOnExposedNames: Module used on exposed type `Dict`.

type alias Dict k v =
    Internal.Dict k v
    ^^^^^^^^^^^^^

It is not necessary to use the module here as `Dict` was exposed on import.

You should remove the module from this call, or remove the name from the import
.. exposing list.

Except it is in fact necessary to do that (and exposing the type is done to import the constructors/variants, so can't be avoided)

[sparksp]

Thank-you for the SSCCE. Some more context for this, so that it's not lost. The original bug report on Slack...

I'm running into a bit of a problem with elm-review. I have something like

module MyModule exposing (Thing)

import MyModule.Internal exposing (Thing(..))

type alias Thing = MyModule.Internal.Thing

... functions that use Thing(..) ...

Now elm-review complains about the type alias and wants to change it to type alias Thing = Thing which does not compile.

I can easily work around the problem locally, of course, but I am wondering if elm-review could be made to handle this?

[sparksp]

I have taken a look in to this today and found a few things I want to note for myself (or another fixer)...

• This code uses a NameVisitor to look at each Type used in isolation; this means that we don't have any information about the type alias when it is being reported on.
• Using a declarationListVisitor will mean that we can note that a Type is being shadowed and possibly ignore it, however this may mean that any fully qualified use of the type will also have to be ignored (possible false positive), unless the NameVisitor is removed (big effort).
• Since the NameVisitor also uses a declarationListVisitor, it may be necessary to defer error reporting until final module evaluation, and gather possible naughty Types in the context until then (some effort). At the moment errors are returned directly from the visitors.