Bad cabal build error message with mangled top of file

[bos]

(Imported from Trac #893, reported by @rrnewton on 2011-10-02)

I accidentally executed an Emacs keystroke that switched tokens around and mangled the top of my file:

{-# Language BangPatterns?, CPP #-} # OPTIONS_GHC
{--fno-warn-name-shadowing -fwarn-unused-imports #-}

When GHC is run directly on this file it gives a sensible error message

Control/Monad/Par/Stream.hs:1:36: parse error on input `#'

But when building through cabal build it looks like there is a module-name-finding heuristic that is failing (and defaulting to Main), resulting in this weird error message:

Building monad-par-0.1.0.2... Control/Monad/Par/Stream.hs:1:1:

File name does not match module name: Saw: `Main' Expected: `Control.Monad.Par.Stream'

Which really caused me to scratch my head when I saw it ;-). ("No where does it say Main!!") I was afraid I had messed up paths and was loading a different version of the file from another directory or something...

[manzyuk]

I don't think this is a cabal bug.

I tried to reproduce this behaviour: I downloaded monad-par-0.3.4.1 and mangled the file Control/Monad/Par/Scheds/Direct.hs so that its top looked as follows:

{-# LANGUAGE RankNTypes, NamedFieldPuns, BangPatterns,
             ExistentialQuantification, CPP, ScopedTypeVariables,
             TypeSynonymInstances, MultiParamTypeClasses,
             GeneralizedNewtypeDeriving, PackageImports,
             ParallelListComp
             #-} # OPTIONS_GHC
{- -Wall -fno-warn-name-shadowing -fno-warn-unused-do-bind #-}

Running GHC directly on this file gives the following error message:

Control/Monad/Par/Scheds/Direct.hs:6:18: parse error on input `#'

Building through cabal build produces the following error message:

Control/Monad/Par/Scheds/Direct.hs:1:1:
    File name does not match module name:
    Saw: `Main'
    Expected: `Control.Monad.Par.Scheds.Direct'

However, running GHC on Control/Monad/Par.hs produces an identical error message.

I'm guessing that something like this is happening:

• when GHC is run directly on Control/Monad/Par/Scheds/Direct.hs, it tries to parse a module declaration, encounters # OPTIONS_GHC, decides that the file doesn't have a module header (in particular, defaults the module name to Main), tries to parse # OPTIONS_GHC and fails;
• when GHC is run on Control/Monad/Par.hs, it expects to find a module named Control.Monad.Par.Scheds.Direct in the file Control/Monad/Par/Scheds/Direct.hs, but when it tries to parse it it encounters # OPTIONS_GHC, and decides that the file doesn't have a module header, defaults the module name to Main, and fails with a different error.

This theory is supported by the following experiment: replace the pragmas and # OPTIONS_GHC above with some code, e.g., foo = 3. Then running GHC on Control/Monad/Par/Scheds/Direct.hs produces

Control/Monad/Par/Scheds/Direct.hs:12:1:
    parse error on input `module'

and running GHC on Control/Monad/Par.hs produces

Control/Monad/Par/Scheds/Direct.hs:1:1:
    File name does not match module name:
    Saw: `Main'
    Expected: `Control.Monad.Par.Scheds.Direct'

The summary of the above is that this is not a cabal bug (and probably not a bug at all), and this ticket should be closed.

[tibbe]

Good analysis. Closed as not a Cabal issue.