[GHC] #8029: batch-mode recompilation checking sometimes fails
#8029: batch-mode recompilation checking sometimes fails -----------------------------+---------------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: recompilation, batch-mode Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The batch-mode recompilation checker seems to be broken. Suppose you have a source tree with {{{ Data/List.hs Data/Top.hs }}} and Data/List.hs defining 'foo' and Data/Top.hs importing Data.List (local file). Compile Data/Top.hs, then rename Data.List so you have {{{ Data/List.{hi,o} Data/OtherList.hs -- exports 'foo' Data/Top.hs -- imports Data.List and Data.OtherList Data/Top.{hi.o} }}} Attempting to run 'ghc -c Data/Top.hs' will now fail with " Failed to load interface for `Data.OtherList'". This error appears to be specific to built-in modules, if I use a library module (e.g. Data.Vector from the vector package) I instead get an error that multiple definitions of 'foo' are in scope. A test repo is available at https://github.com/JohnLato/tripping-octo- avenger Incidentally, everything works if I use 'ghc -c --make'. I think a reasonable fix would be for --make to be on by default for batch-mode compilation as well. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8029 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8029: batch-mode recompilation checking sometimes fails ------------------------------------------+--------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: recompilation, batch-mode | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ------------------------------------------+--------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I'm not sure what the problem is here. It is ''always'' true that if you have {{{ A.hs module A where import NonExistent }}} and you compile `A.hs` without first compiling `NonExistent.hs`, you'll elicit {{{ Failed to load interface for `Data.OtherList' }}} The `--make` mode says to make the dependencies first, but you aren't doing that. So GHC seems to be behaving precisely as advertised, no? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8029#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8029: batch-mode recompilation checking sometimes fails ------------------------------------------+--------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: recompilation, batch-mode | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ------------------------------------------+--------------------------------- Comment(by jwlato): Sorry, it seems I cut it down too far. I was originally working in the context of parmake, which was compiling the other module first. That also explains the other error, which makes more sense now. If OtherList.hs is compiled first, so all the dependencies exist, I get {{{ Data/Top.hs:7:5: Ambiguous occurrence `foo' It could refer to either `Data.List.foo', imported from `Data.List' at Data/Top.hs:3:1-16 or `Data.OtherList.foo', imported from `Data.OtherList' at Data/Top.hs:4:1-21 }}} However, I'm not entirely convinced this is an actual bug. What I would like is for ghc to notice that Data/List.hs no longer exists and determine that Top's reference to Data.List must refer to the package-provided module, thereby ignoring Data/List.{hi,o}. That would limit the utility of batch-mode compilation though, as probably one use case for batch-mode is compiling modules when you may not have access to all the prior source, just the interface/object code. The behavior necessary to support that seems rather surprising, which is why I opened the ticket in the first place. Anyway, feel free to close as invalid/wontfix, unless you see a way to do everything properly. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8029#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8029: batch-mode recompilation checking sometimes fails ------------------------------------------+--------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: recompilation, batch-mode | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ------------------------------------------+--------------------------------- Comment(by simonpj): Ah, now I understand. Here is what is happening, when using `OneShot` mode, i.e. the "`-c`" flag: * From `import Foo` GHC looks for `Foo.hi` in some exposed package. * When it finds that file, it trusts it. * In this case, `Data/List.hi` exists and is trusted; but actually `Data/List.hs` has gone away. * As you say, for installed packages, the `.hs` files may legitimately not exist. Dealing with the dependencies between `.hi` files and `.hs` files is really what `--make` is for, but I can see the confusion. Here are a couple of suggestions * We could easily make the error message say {{{ It could refer to either `Data.List.foo', imported from `Data.List' (package base) at Data/Top.hs:3:1-16 or `Data.OtherList.foo', imported from `Data.OtherList' at Data/Top.hs:4:1-21 }}} That is, add `(package X)` to say which package the module is from. Probably nothing for the "home package". That might help a little. * A bit harder would be this: for the '''home''' package only, we ''do'' expect source files to exist. So I suppose `Finder.findHomeModule` could look for the source file too, and complain if it finds a `.hi` file without a corresponding `.hs` file (and maybe also check modification times). But of course that too is only a sticking plaster. The source file might exist, and the `.hi` file might have a later modification time; but it might still all be out of date because some module lower down is out of date. And that takes you back to `--make`. Design suggestions, and subsequent patches, would be welcome! Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8029#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC