Bad cabal build error message with mangled top of file #883

Closed
bos opened this Issue May 24, 2012 · 2 comments

3 participants

@bos
Haskell member

(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
Haskell member

Good analysis. Closed as not a Cabal issue.

@tibbe tibbe closed this May 4, 2013
@hanjoosten hanjoosten referenced this issue in commercialhaskell/stack Dec 20, 2015
Closed

File name does not match module name: Saw: `Main' #1549

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment