ghc --make reports bad import errors too eagerly

Consider this A.hs file, with a valid header (no B.hs file) and a syntax error:

module A where
import B

= as7df89a235r a23jk @A#$(&#$A 

We get different behavior when one-shot compiling and make compiling:

ezyang@sabre:~$ ghc -c A.hs

A.hs:4:1: parse error on input `='
ezyang@sabre:~$ ghc --make A.hs

A.hs:2:8:
    Could not find module `B'
    Use -v to see a list of the files searched for.

I feel like the --make error is wrong, and we shouldn't actually complain that an import is missing until we build it. But it cuts both ways; if you have a big module graph and you try to --make, currently --make will report instantaneously if any import is wrong; if we changed this behavior, --make would chug along until it actually tried to compile the offending file.

It's easy to fix and I can easily submit a patch for it, if people think we should defer the error. Doing this will also let me remove a grievous hack from my fix to #11244 (closed).

Trac metadata

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

changed milestone to %8.0.1

changed weight to 5

added Tbug Trac import labels

You could try validating such a fix, if it really is not too much work. There might very well be a regression test against it. Then you could look to see if there is any discussion in the corresponding ticket.

I am not sure which option is better from a users' perspective. I would go for the one that makes the implementation of --make the simplest.

With the fix, three test cases see a diff like the following:

-Q.hs:3:8:
-    Could not find module ‘Data.Set’
-    It is a member of the hidden package ‘containers-<VERSION>@containers-<VERSION
>’.
+Q.hs:3:1:
+    Failed to load interface for ‘Data.Set’
+    It is a member of the hidden package ‘containers-<VERSION>’.
     Perhaps you need to add ‘containers’ to the build-depends in your .cabal file.
     Use -v to see a list of the files searched for.

Arguably, "Could not find module" is a better error message; however, this is indeed the message -c gives when it can't find the module, so surely it can't be that bad?

Yeah, that seems fine.

Trac metadata

Trac field	Value
Differential revisions	- → D1669

mentioned in commit ff3f918d

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

mentioned in issue #11596

added Pnormal label

mentioned in merge request !3342 (closed)