Bogus "Module does not export&quo...

Help
Jarno
2011-01-10
2012-12-06
  • Jarno
    Jarno
    2011-01-10

    I'm doing a major refactoring/redesign in my project, and while the work is in progress there are several errors in compilation. However, EclipseFP is not showing the proper error messages but instead it is showing dozens of "Module x does not export y" and "attempting to use module x which is not loaded" messages when the module x does indeed export y and compiles just fine.

    When building the project EclipseFP flashes the proper error messages but replaces them with "does not export" and "attempting to use" errors in a few seconds. Sometimes restarting Eclipse helps for a while, but not always.

    Cabal install on command line shows the proper errors, not any "does not export" or "attempting to use" errors.

    Below is a snippet of the console log that shows how scion gives proper errors first in "load" method, but then gives "does not export" and "attempting to use" errors in "background-typecheck-file" method.

    Is this a problem in Scion or EclipseFP or is there something I should do differently?

    Thanks,
    Jarno

    << {"id":214,"method":"load","params":{"component":{"executable":"kannat","cabal-file":"/Users/jarno/Work/Haskell/xyz/xyz.cabal"},"options":{"forcerecomp":false,"output":true}}}
    >> {"id":214,"result":{"succeeded":false,"duration":0.074891,"notes":[{"message":"Couldn't match expected type `Expression'\n       against inferred type `FunctionDefinition'","location":{"region":,"file":"/Users/jarno/Work/Haskell/xyz/src/Xyz/Expression.hs"},"kind":"error"},{"message":"Couldn't match expected type `Expression'\n       against inferred type `FunctionDefinition'","location":{"region":,"file":"/Users/jarno/Work/Haskell/xyz/src/Xyz/Expression.hs"},"kind":"error"}]},"version":"0.1"}
    << {"id":215,"method":"load","params":{"component":{"executable":"xyz-selenium","cabal-file":"/Users/jarno/Work/Haskell/xyz/xyz.cabal"},"options":{"forcerecomp":false,"output":true}}}
    >> {"id":215,"result":{"succeeded":true,"duration":0.012203,"notes":},"version":"0.1"}
    << {"id":216,"method":"load","params":{"component":{"executable":"xyz-unittest","cabal-file":"/Users/jarno/Work/Haskell/xyz/xyz.cabal"},"options":{"forcerecomp":false,"output":true}}}
    >> {"id":216,"result":{"succeeded":false,"duration":0.088431,"notes":[{"message":"Couldn't match expected type `Expression'\n       against inferred type `FunctionDefinition'","location":{"region":,"file":"/Users/jarno/Work/Haskell/xyz/src/Xyz/Expression.hs"},"kind":"error"}] (cut several other errors)},"version":"0.1"}
    << {"id":217,"method":"parse-cabal","params":{"cabal-file":"/Users/jarno/Work/Haskell/xyz/xyz.cabal"}}
    >> {"id":217,"result":{},"version":"0.1"}
    << {"id":218,"method":"cabal-dependencies","params":{"cabal-file":"/Users/jarno/Work/Haskell/xyz/xyz.cabal"}}
    >>
    {"id":218,"result":[{"/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.1/package.conf.d":[{"exposed":true,"name":"utf8-string","dependent":,"modules":["Codec.Binary.UTF8.String", ]}],"version":"0.1"}
    << {"id":219,"method":"background-typecheck-file","params":{"file":"/Users/jarno/Work/Haskell/xyz/src/Xyz/Expression.hs"}}
    >>
    {"id":219,"result":{"Right":{"succeeded":false,"duration":0.056115,"notes":[{"message":"Module
    `Xyz.Document' does not export
    `Document(DocumentRef)'","location":{"region":,"file":"/Users/jarno/Work/Haskell/xyz/src/Xyz/Expression.hs"},"kind":"error"},{"message":"attempting to use module `Xyz.Json' (src/Xyz/Json.hs) which is not loaded","location":{"region":,"file":"/Users/jarno/Work/Haskell/xyz/src/Xyz/Expression.hs"},"kind":"error"}
    (cut dozens of similar messages) ]}},"version":"0.1"}

     
  • JP Moresmau
    JP Moresmau
    2011-01-10

    Unfortunately I have never seen such behavior, so I'm at a loss. It seems that the errors are properly reported when the project is built, but we we try to analyze an individual file the errors suddenly change to something else.
    One thing that may cause these issues is the fact that you have several cabal components in your file, and maybe the code is trying to analyze the source file in the wrong component? The code usually tries to find one component (one executable definition for example) that includes the module and use this setting to build the project. Maybe through Cabal not all components are built, and in fact some are wrong? I mean maybe your test executable does not include properly all the modules, and it's not built by Cabal by default, but EclipseFP picks it up and uses that to build your file? I think at the moment we don't check for "buildable" flags.
    So you could try leaving only one executable in your cabal file and see it the behavior is correct then. That could confirm that theory.

     
  • JP Moresmau
    JP Moresmau
    2011-01-10

    I've actually managed to briefly reproduced. I modified source code to create errors and suddenly I got the same errors as you did. Reopening the referenced files that were reported in the messages solved the problem. Now I cannot reproduce, so it seems to be something related to the reloading of dependent packages. But we do pass flags to force GHC to recompile all packages… I will see if I can reproduce again, but it seems very elusive. So in your case, try opening Xyz.Document and Xyz.Json in EclipseFP, then close and reopen Expression.hs.

     
  • JP Moresmau
    JP Moresmau
    2011-02-04

    It's hard to be sure because of the nature of the bug, but I think I've nailed it. There was some code in scion reloading modules when there was no need, and I think that's why we had unloaded modules. This will be part of the next version, and is available in the github repository.

     
  • Jarno
    Jarno
    2011-03-23

    Looking good so far, I haven't seen the problem any more. Thanks a lot!