Misleading GHCi errors when package is installed

When a package is installed in a cabal sandbox/global package directory and code is loaded with GHCi when a file has been deleted, GHCi gives very misleading errors.

First, if we don't install the package, we get the correct error/expected result:

> mv B.hs B.hs.old
> ghci Main.hs
Main.hs:3:1: error:
    Failed to load interface for ‘B’
    Use -v to see a list of the files searched for.
Failed, modules loaded: A.

But if we first install the package, we get a very strange error:

> mv B.hs.old B.hs
> cabal install
> mv B.hs B.hs.old
> ghci Main.hs
Main.hs:6:14: error:
    Ambiguous occurrence ‘str’
    It could refer to either ‘A.str’,
                             imported from ‘A’ at Main.hs:2:1-8
                             (and originally defined at A.hs:7:1-3)
                          or ‘B.str’,
                             imported from ‘B’ at Main.hs:3:1-8 (and originally defined in ‘A’)
Failed, modules loaded: A.

I'm using GHC 8.0.1, cabal-install-1.24.0.0, and Cabal Library-1.24.0.0.

This is Very Annoying because I use this process to minimize examples. For example, when I want to simplify code by removing a module, I just delete it and then rely on GHCi to tell me what I need to update. Anyone not aware of this bug would be totally confused by the error, and even though I do know about the bug, the error is completely unhelpful.

Trac metadata

Trac field	Value
Version	8.0.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added GHCi Tbug Trac import labels

Attached file test2.tar (download).

changed weight to 7

Trac metadata

Trac field	Value
Priority	normal → high
Related	- → #11536

Hmm, ezyang do you have any idea of what might be happening here?

I think the answer is, "You shouldn't use cabal install, full stop. But you *especially* shouldn't use it on code you are editing and recompiling."

Here's what's happening:

1. When you cabal install the package, it gets added to the user package database. This means that if you run ghci without any flags, all of the modules from this package are available for import.
2. When you ghci Main.hs, it first looks to see if there's a local B.hs. There is none, so then it looks to see if any exposed packages in the databases its using (including the user one) have B. The one that cabal install'ed is there, so it uses that! And so now you have two versions of A in scope: one that came from the cabal install'ed package, and one that was locally interpreted by bytecode.

I think GHC's error messages here could be a lot better. But that's what's happening. If you unregister the installed package (ghc-pkg unregister) you'll stop picking up the installed copy.

My current workflow requires using cabal install, and I'm not aware of another option (though I'm open to suggestions. I'm not sure if this problem occurs with stack or not, but either way stack still doesn't have an LTS resolver for GHC 8.0.) I wrote a library, and also a separate program which depends on that library. Thus the library must be cabal-installed to build the second program (this is true even if I use add-source in cabal). Then when I go back to make changes to the library, the error above can occur.

Note that in this workflow, it is never necessary to ghc-pkg unregister the library: if I build with cabal, it detects the changed source and automatically rebuilds/installs, and if I use ghci it uses the source code.

Try using cabal new-build (http://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/), it's designed *exactly* for your use-case. Actually, sandboxes should have also worked, but sandboxes are buggy and you should use new-build instead.

I know that GHCi picks up local modules, and so it is just in the particular case you've reported here that things work poorly (missing local module). But it is hard to see how we can behave differently. On workaround for this particular case is to set exposed: False in your Cabal file, so that it is NOT pulled in by default when you invoke GHCi. Maybe that's good enough for you, if you don't want to use new-build?

For the record, I was using a (common) sandbox for the library and the other program.

In addition to cabal new-build and setting expose: False, another workaround is to use -hide-package mylib when invoking GHCi. This results in a semi-reasonable error:

Failed to load interface for ‘<Deleted file>’
 It is a member of the hidden package ‘mylib-0.0.0.1’.
 Use -v to see a list of the files searched for.

It's certainly an improvement over not using -hide-package.

@ezyang I have switched over to stack, and I'm still having this issue. My libraries are not installed in the global package index, but when I try to use GHCi (stack exec ghci -- path/to/my/lib), I get these errors.

If you don't think this is a issue with GHC, please let me know where I should report it. Otherwise, I'd say that this issue affects multiple tools, and should be resolved.

What are the steps to reproduce using STack?

Attached file 12395.tar.gz (download).

example with stack

@ezyang The attached example demonstrates the problem:

> stack test b
<completes successfully>

> stack exec ghci -- b/Main.hs
b/Main.hs:6:14: error:
    Ambiguous occurrence ‘str’
    It could refer to either ‘A.str’,
                             imported from ‘A’ at b/Main.hs:2:1-8
                             (and originally defined at a/A.hs:7:1-3)
                          or ‘B.str’,
                             imported from ‘B’ at b/Main.hs:3:1-8
                             (and originally defined in ‘A’)
Failed, modules loaded: A.

The issue may be related to my .ghci file: I have :set -ia, but do not give a path to b. If I give paths to a and b, or neither, it appears to compile fine. Thanks for looking into this!

added error messages label

added Phigh label