-fwarn-unused-imports complains about wrong import

Good bug report. Alas, it's not easy to fix. Here's why.

To report unused imports, GHC gathers up all the entities that are referred to (Names, in GHC's terminology). But that doesn't say *how* they are referred to, so it does not distinguish 'ap' from 'Control.Monad.ap'.

In this case, the import of Control.Monad is indeed required, because the reference was a qualified one.

So really this exposes an architectural shortcoming in the way GHC reports unused imports. Of course it's fixable, but it'd be non-trivial, so don't hold your breath.

Simon

I assume that this is the same bug, that I encountered, too. It is possibly the same like http://hackage.haskell.org/trac/ghc/ticket/1148 I remember that such wrong warnings occured when switching from GHC 6.2 to GHC 6.4. Here I have setup a self-contained example:

http://users.informatik.uni-halle.de/~thielema/Haskell/ImportWarning/

I insert the example here:

module A where

type T = Int

module B ( module A ) where

import A

module C where

{-
This import is necessary but is reported as unnecessary.
"necessary" means:
If you remove that import statement, then the module cannot be compiled.
Of course, we could use the identifiers from B,
since B just re-exports A.
But formally I consider it a bug to declare the import of A as unnecessary.
-}
import qualified A

{-
This import is unnecessary but no warning is emitted.
If this import is removed, everything compiles fine without warnings.
-}
import B


f :: String -> A.T
f = read

I think this is the same bug, that I ran into:

module Foo where
import qualified Prelude as A (take)
import qualified Prelude as B

Warning: Imported from `Prelude' but not used: `B.take'

The module it refers to is the last applicable one in the import list - even if there would never be a warning about importing a particular identifier when it is not explicitly named in a relevant import list, and even if B.somethingElse is used. Re-ordering the imports "fixes" the warning; also, adding ...as B hiding (take) "fixes" it. Maybe this bit is fixable, assuming ghc remembers the import lines...

Also I noticed that replacing take with Int results in no warning at all - is this intentional? (note that, apparently GHC *never* gives unused-*module*-import warnings for Prelude, if considering this)

P.S. if {{{"necessary" means: If you remove that import statement, then the module cannot be compiled.}}} then GHC is designed (whether or not I agree with that design) to warn about those, when the only uses of that import are by function definitions that are never used or exported.

Thanks for further examples. The more examples we have, the more likely we are to get it right when we eventually fix this one! (It's trickier than one would think.)

But as my comment above says, to fix it properly requires some real work, and since it's (by definition) not a show-stopper, it's not top of the priority list. (Unless you all say it is!)

Simon

When fixing this, be sure to fix #1384 at the same time.

Simon

Here's the behaviour I'd like:

For each use of a variable foo, mark imports

import M (..., foo, ...)

as "used" if any exist; otherwise mark any imports

import M

which export foo as "used". Mark all imports of the form

import M ()

as used.

Then warn about any imports not marked as "used".

See also #2267.

This is biting more and more people, as warnings are increasingly enabled by users. Also, it's a real pain to workaround. Let's just rewrite the warning code and fix it.

See also #2681, #1148, #2267.

(nb. my algorithm above needs extending to work with qualified imports too)