Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

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

Closed
bos opened this Issue · 2 comments

3 participants

@bos
Owner

(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
Owner

Good analysis. Closed as not a Cabal issue.

@tibbe tibbe closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.