Another module than given in `main-is` is picked as main module

[andreasabel]

If the module in main-is has a name and there is another module that has no explicit name (no module header), then the other module is picked as main module.

Bar.hs

main = putStrLn "I am the shady main..."

Foo.hs

module Foo where

main = putStrLn "I am the real main!"

wrong-main.cabal

cabal-version: 1.12
name:           wrong-main
version:        0.0.0
build-type:     Simple

executable wrong-main
  main-is: Foo.hs
  other-modules:
      Bar
      Paths_wrong_main
  hs-source-dirs:
      ./
  build-depends:
      base
  default-language: Haskell2010

$ cabal run
...                                                                                                       
I am the shady main...

Packaged reproducer: wrong-main.tgz

Analysis: It seems Cabal calls GHC this way:

ghc --make -fbuilding-cabal-package -O -static ...  -XHaskell2010 ./Foo.hs Bar Paths_wrong_main ...

The correct result can be obtained by adding -main-is Foo:

ghc --make -main-is Foo Bar.hs Foo.hs    

I suppose the difficulty is to extract the module name Foo from Foo.hs, since -main-is does not accept a file, just a qualified (module) name.

(I am having a dejavu here, but I couldn't find a report for this issue.)

Stack has the same problem:

• Cabal's main-is field (source file) does not alter GHC's -main-is option (module and function name) commercialhaskell/stack#6695

[phadej]

I think the real issue is that

 other-modules:
      Bar

is accepted, while Bar.hs contains module Main. there aren't module Bar.

And I don't have a good solution to this problem.

I thought long ago, that if GHC accepted arguments something like Bar:path/to/SomeFile.hs, then it would solve this issue; and also make it possible to turn automatic module discovery in GHC (which would allow components to share hs-source-dirs). In this case GHC should complain if module name and given module paths don't agree.

Then we allow different syntax for main-is, matching the above main-is: Foo:Foo.hs, and treat old variants, i.e.
main-is: Foo.hs as if they were main-is: Main:Foo.hs.

TL;DR, the core problem is that Cabal and GHC have to no way to communicate module <-> path mapping; and Cabal has to "reverse-engineer" what GHC is doing, instead of being explicit, and just telling GHC where to look for the sources.

I.e. I think this is GHC design issue. Parsing Haskell files to figure out module names is not something Cabal should even consider doing. (For example there could be custom literate preprocessor, or even just complicated CPP)