Suspicious state from syntax checker haskell-ghc...

[flycheck]

Suspicious state from syntax checker haskell-ghc...

[swsnr]

@mrkkrp I've reverted the corresponding change, so the next MELPA build should work again.

Inviting @gracjan, because he wrote that code.

[gracjan]

Well, it says exactly what it means: you cannot flycheck your executable until your library is available.

In my projects that have both libraries and executables I source all library files into executable just for this reason.

[mdorman]

I believe my #31 handles this appropriately. It's not an issue with the user's configuration, it's a result of using the overly-simplistic flattenPackageDescription.

[gracjan]

I do not see how #31 enables to use library before it is build, but if it does then that's great!

[swsnr]

@gracjan It used to work before, apparently, so it's not that easy, and I don't think that sarcasm is going to make it any easier for us to deal with this issue.

@mdorman As far as I'm concerned this is getting a little out of hand. I don't know whether #31 solves it or not, for I didn't take a closer look yet, but if we need to copy code from Cabal it's the wrong way obviously, at least from my point of view.

It's a probably sign that we need upstream support—i.e. a cabal command to dump the current build configuration in a structured format—but in the absence thereof I'd rather revert the entire change, and not extract any dependencies at all. In the rare cases where this breaks due to ambiguous imports, I'd rather let the user intervene manually instead of complicating our Haskell helper.

[mdorman]

I am not going to pretend to be all that expert in this, @gracjan. It's mostly just observation an testing. However, if you look at the output of the script, you see something like:

((build-directories "/home/mdorman/src/couch-simple/dist/build" "/home/mdorman/src/couch-simple/dist/build/autogen")
 (source-directories "/home/mdorman/src/couch-simple/src/lib" "/home/mdorman/src/couch-simple/test")
 (extensions)
 (languages "Haskell2010")
 (dependencies "aeson" "attoparsec" "base" "bytestring" "containers" "data-default" "directory" "either" "errors" "exceptions" "file-embed" "filepath" "hjsonschema" "hlint" "hspec" "http-client" "http-types" "lens" "lens-aeson" "mtl" "random" "tasty" "tasty-hunit" "template-haskell" "text" "transformers" "unordered-containers" "uuid")
 (other-options "-Wall"))

Given that source-directories includes the library directory, I believe ghc will be able to find the library files even when checking the executable source. The problem I believe he was running into was that the name of the library was also being included in the list of dependencies, and GHC was complaining that it couldn't find it because it wasn't installed---which masked its ability to resolve to the source files themselves.

[swsnr]

@gracjan #31 filters references to the current package from the list of build dependencies, so GHC will fall back to resolving intra-package imports from the source files as it did before.

[mdorman]

@lunaryorn That is of course your prerogative, though I would urge you not to do so.

The fact is, while better cabal support for this would undoubtedly be nice---heck, it would be great if there were a "spit out dependencies, etc. for this file" api---that's at best a year in the future?

The code I borrowed from Cabal is, if you actually look at it, quite mundane---it's really just doing deep updates on a data structure. If one were to deploy Control.Lens against it, it would turn into a one-liner that might not even look like line noise. :)

I can't pretend to be totally objective, obviously: I put the effort into a solution, so of course my ego wants to see it go in. Still, if you really think the whole business is a maintenance burden, though, I will understand.

In fact, maybe there's a further issue: the code that's in there isn't even compatible with cabal-1.22, so there's even some CPP that will likely become necessary before long. Maybe it is best to just rip it out.

[swsnr]

@mdorman If you don't mind, I'd prefer if we discussed the details of your implementation in #31. It's easier for me if everything is in the right place, and if we are discussing code, it's best to have the code right at hand. Thanks :)

[gracjan]

@lunaryorn, @mdorman, sorry about the sarcasm, it was directed at Cabal as a complicated piece of software that surprises me much more often that I would like it to.

About the issue at hand:

Sourcing all and every source directory is one way. Another way is to have 'configurations, that is flycheck-haskell-configure should accept as an argument telling which part of .cabal file are we working with this time.

The latter may cause more surprises as it is not clear if cabal will pick the library you are just right now editing or maybe it will pick one of the already installed ones (has happened to me, lost half a day due to my edits not taking effect. It was in the context of cabal repl). I guess that is also why 'it use to work', in a sense, because it was picking some library that was installed.

For that reason alone I advocate no interdependencies inside .cabal files.

@mdorman: if #31 filters interdependencies, then I guess it 'works'. The caveat is that it does something else than what cabal-install would do.

[swsnr]

@gracjan “Do what cabal-install does” is not the scope of this project. My aim is to get the same error reporting in most situations, with as little effort as possible. The simpler, the better, and if it breaks in some corner cases or fails to spot some more obscure errors, that's ok, as far as I'm concerned, for Flycheck does generally not aim to replace a build tool.

In other words, you'll always have to run cabal build to get an accurate impression of the current state of your project. Flycheck is just about giving you a close enough approximation within the scope of the current file.

[mrkkrp]

@gracjan, adding source files of library to every dependent item in .cabal file to avoid interdependencies is conceptually wrong in my opinion. For example, test suite should obviously depend on library. See pipes library and other prominent projects for example.

I don't see any reason why flycheck couldn't check source code of executable if it can locate source code of library.

[gracjan]

@lunaryorn: I do not understand your comment at all.

If 'most situations' you are talking about cover all .cabal files without internal dependencies and if by 'breaks in some corner cases' you mean breaks for .cabal files with internal dependencies... then you get issue reports like this one.

@mrkkrp: test suite should depend on sources of the library, moreover it is valuable if test suite has access to not exported modules for testing purposes.

You are advocating that flycheck should locate source code of the library, I say that you are exactly right and that you should just state it explicitly in the .cabal file.

[swsnr]

@gracjan A cabal project with internal dependencies is not a “corner case”, obviously. And I don't think that you should have to write your Cabal file in any specific way to get Flycheck working properly.

[mrkkrp]

@gracjan, it doesn't work very well for me, because my library and executable share the same directory src at the moment, let alone test suite (which is in different directory tests).

[gracjan]

@mrkkrp: so... the only thing you need flycheck-haskell-configure to do is to filter out internal dependencies and that is all?

@lunaryorn: I do not follow your definitions of 'corner case' vs anything else. For example as far as I know TemplateHaskell is still unsupported by official flycheck-haskell (I still use my own patched version).

Anyway: in my opinion Cabal is super complicated and uses way to much black magic, so that every other tool like flycheck-haskell has to apply some white magic to undo what was done. @mrkkrp wants flycheck-haskell to do exactly what I advocate to do explicitly. Well, I guess it must be done as we are not going to convert every .cabal file out there. Warning from me is that this will introduce more uneasy surprises. Lets wait till backpack lands, then real trouble will start...

[swsnr]

@gracjan Flycheck breaks on projects which define their own Template Haskell operators because of the way GHC builds—specifically GHC wants TH operators compiled ahead of time. That makes it close to impossible to support TH without completely compiling the entire module, which in turn isn't a good idea either, because code generation takes long on large modules.

But there are very few projects that define their own TH operators, so yes, internal TH dependencies are a corner case.

Projects which just some other libraries TH operators (e.g. projects that just use Lens) work fine with Flycheck.

You are probably right to warn about possible side effects. We all know that this could break. But it was broken before, too.

It is a hack, there's no denying that. And I have not heard any better suggestion from you either…

[gracjan]

I have advocated better solution many times over so I do not feel the need to repeat myself again. I'm using my forked version of flycheck and I'm happy with it. Especially with the improved speed as my version does not have to recompile all of 250 modules at every change.

[swsnr]

I have advocated better solution many times over so I do not feel the need
to repeat myself again.

I'm sorry, but I don't remember. Wasn't it your pull request that proposed to extract more information from the Cabal file? What better solution than that did you advocate?

I'm using my forked version of flycheck and I'm happy with it. Especially
with the improved speed as my version does not have to recompile all of 250
modules at every change.

I'm curious to see it, but I'd like to focus on this issue. Specifically, how can we refine the extraction of build information from the Cabal file so that it matches the actual build more closely?