GHC 8.2.1 support

[LeventErkok]

There seems to have been some attempts to get ghc-mod working with 8.2.1; curious what the status of that work is. Thanks for this great software; now that I upgraded to 8.2.1, I'm really missing it!

[DanielG]

I don't have any plans to work on it myself in the near future and I don't know of anyone who is but patches are welcome and I'd be happy to help on IRC.

[DanielG]

PR: https://github.com/DanielG/ghc-mod/pull/911

[Qinka]

(I wonder when ghc-mod is available for GHC-8.2.1)????

[DanielG]

This is blocking on cabal-helper support for Cabal-2.0 currently.

Most of the boring busy work on that front is already done, the CI is green for all currently supported Cabal versions and we have a straight forward test case which fails with Cabal-2 but works with older versions. Basically removeInplaceDeps needs to be adapted to Cabal-2's way of doing inplace dependencies.

Firstly we need to support internal libraries which the code currently just ignores and secondly we need to figure out what to do when we get backpack stuff (ModuleRenaming etc.)

The current implementation is a hack since we're inlining the GHC options for multiple components into one GHC invocation. That worked pretty well before backpack but now -package flags can specify module renamings which we can't express just by merging include dir (-i) AFAICT and other options in the right order as we were doing before.

[zemanlx]

Looks like that cabal-helper:master now works with Cabal-2.0 and GHC-8.2.2 :tada:

[HuStmpHrrr]

Hi, it's a kind inquiry on what's remained to be done for it to support ghc 8.2.2?

[mrkgnao]

@HuStmpHrrr and everyone else: you can now build ghc-mod for 8.2.2 with cabal-helper master, as outlined here:

https://github.com/DanielG/ghc-mod/pull/922#issuecomment-353896120

I have it working successfully on NixOS.

[jwiegley]

@mrkgnao Can you share the expression you're using? I can't seem to find a combination that works. Thanks.

[mrkgnao]

I use rien (which is just a few Nix scripts) to do the overriding of cabal-helper with my local checkout, which essentially copies what Gabriel does here.

I then just add ghc-mod as a dependency in shell.nix for my projects, like so. This should be easy to replicate in your setup. :)

ghc-mod just has a couple fiddly dependencies removed (e.g. shelltest):

{ mkDerivation, base, binary, bytestring, Cabal, cabal-doctest
, cabal-helper, containers, criterion, deepseq, directory
, djinn-ghc, doctest, extra, fclabels, filepath, ghc, ghc-boot
, ghc-paths, ghc-syb-utils, haskell-src-exts, hlint, hspec
, monad-control, monad-journal, mtl, old-time, optparse-applicative
, pipes, process, safe, semigroups, split, stdenv, syb
, template-haskell, temporary, text, time, transformers
, transformers-base
}:
mkDerivation {
  pname = "ghc-mod";
  version = "5.8.0.0";
  src = ./.;
  isLibrary = true;
  isExecutable = true;
  enableSeparateDataOutput = true;
  setupHaskellDepends = [
    base Cabal cabal-doctest containers directory filepath process
    template-haskell transformers
  ];
  libraryHaskellDepends = [
    base binary bytestring cabal-helper containers deepseq directory
    djinn-ghc extra fclabels filepath ghc ghc-boot ghc-paths
    ghc-syb-utils haskell-src-exts hlint monad-control monad-journal
    mtl old-time optparse-applicative pipes process safe semigroups
    split syb template-haskell temporary text time transformers
    transformers-base
  ];
  executableHaskellDepends = [
    base binary deepseq directory fclabels filepath ghc monad-control
    mtl old-time optparse-applicative process semigroups split time
  ];
  testHaskellDepends = [
    base cabal-helper containers directory doctest fclabels filepath
    ghc ghc-boot hspec monad-journal mtl process split temporary
    transformers
  ];
  testToolDepends = [ ];
  benchmarkHaskellDepends = [
    base criterion directory filepath temporary
  ];
  homepage = "https://github.com/DanielG/ghc-mod";
  description = "Happy Haskell Hacking";
  license = stdenv.lib.licenses.agpl3;
}

cabal-helper is vanilla cabal2nix:

{ mkDerivation, base, bytestring, Cabal, cabal-install, containers
, directory, exceptions, filepath, ghc-prim, mtl, process
, semigroupoids, stdenv, template-haskell, temporary, transformers
, unix, unix-compat, utf8-string
}:
mkDerivation {
  pname = "cabal-helper";
  version = "0.8.0.0";
  src = ./.;
  isLibrary = true;
  isExecutable = true;
  setupHaskellDepends = [ base Cabal directory filepath ];
  libraryHaskellDepends = [
    base Cabal directory filepath ghc-prim mtl process semigroupoids
    transformers unix unix-compat
  ];
  executableHaskellDepends = [
    base bytestring Cabal containers directory exceptions filepath
    ghc-prim mtl process template-haskell temporary transformers unix
    unix-compat utf8-string
  ];
  testHaskellDepends = [
    base bytestring Cabal directory exceptions filepath ghc-prim mtl
    process template-haskell temporary transformers unix unix-compat
    utf8-string
  ];
  testToolDepends = [ cabal-install ];
  doCheck = false;
  description = "Simple interface to some of Cabal's configuration state, mainly used by ghc-mod";
  license = stdenv.lib.licenses.agpl3;
}

[mrkgnao]

@jwiegley you may have to jailbreak cabal-helper, I think, like I do here:

https://github.com/mrkgnao/preposterous/blob/5b03968d4bf9d206417daa3d562fd16119c57fd6/shell.nix#L13

[jwiegley]

I was able to get ghc-mod building for both 8.0 and 8.2:

https://github.com/jwiegley/nix-config/blob/master/overrides.nix#L249

Oddly, I need to use the ghc802 branch for 8.2, and master for 8.0.

[mrkgnao]

Oh, yes, the original instructions specify that:

git clone git@github.com:ariskou/ghc-mod.git -b ghc802

It confused me too.

[Saul-Mirone]

@DanielG It seems that everything is ready, I wonder when ghc-mod is available for GHC-8.2.1 :)

[hvr]

Oddly, I need to use the ghc802 branch for 8.2, and master for 8.0.

It's less confusing if you're already used to __GLASGOW_HASKELL__'s numbering convention... :-)

[jwiegley]

Oh, hey, that makes total sense @hvr! :)

[DanielG]

Since cabal-helper-0.8.0.0 is on Hackage now I've decided to upload a very preliminary package candidate of ghc-mod to make it easier for people to install before its properly released:

$ cabal install https://hackage.haskell.org/package/ghc-mod-5.9.0.0/candidate/ghc-mod-5.9.0.0.tar.gz

Note that https support in cabal-install is relatively recent, AFAIK its available since 2.0.0.0.

I'm using this on GHC 8.2 myself, older versions of GHC are not tested yet however so don't expect them to work. I will try to keep the candidate version updated as we're inching towards a release so expect it to change.

[tsabirgaliev]

@DanielG great news!

Any hints on how to pull this into a stack based project? With previous versions I just did stack build ghc-mod

[DanielG]

There is a way to add tarballs via a http url to stack.yaml but according to the docs the tarball will be cached forever so you might have to find and delete it manually if and when you want to update to the latest package candidate.

[tsabirgaliev]

Thanks to @DanielG hints, I managed to stack build ghc-mod in my project after adding this to stack.yaml:

extra-deps:
- https://hackage.haskell.org/package/ghc-mod-5.9.0.0/candidate/ghc-mod-5.9.0.0.tar.gz
- cabal-helper-0.8.0.0
- extra-1.5.3
- monad-journal-0.7.2
- optparse-applicative-0.13.2.0
- either-4.4.1.1

[EdmundsEcho]

I was able to get ghc-mod to compile using stack and the extra-deps provided. However, ghc-mod version 5.9.0.0 compiled with GHC 8.2.2 still continues to generate the could not find $libexecdir/cabal-helper-wrapper error.

[domenkozar]

Try using cabal-helper-0.8.0.2

[varosi]

Hooray! I confirm that this branch is buildable on Windows with LTS-10.7 (GHC 8.2.2). But 21 tests fail.

[DanielG]

@varosi interresting on Linux there are only three failing tests remaining: https://gitlab.com/dxld/ghc-mod/-/jobs/52021481. If you could try again with ~master~ the latest commit from the gh802 branch and open a new issue with the whole test output I'd be grateful.

[varosi]

Tested on master, too - #932

[jproyo]

Just to pointed out in case someone face the same issue and regarding @tsabirgaliev comment with stack i could managed to get it work with the following extra-deps in my stack.yaml file.

extra-deps:
  - https://hackage.haskell.org/package/ghc-mod-5.9.0.0/candidate/ghc-mod-5.9.0.0.tar.gz
  - cabal-helper-0.8.0.2
  - extra-1.5.3
  - monad-journal-0.7.2
  - optparse-applicative-0.13.2.0
  - either-4.4.1.1
  - free-4.12.4
  - haskell-src-exts-1.19.1
  - hlint-2.0.11

As you can see i need to add the following deps to @tsabirgaliev's list:

  - free-4.12.4
  - haskell-src-exts-1.19.1
  - hlint-2.0.11

[alanz]

FYI haskell-ide-engine also supports the various recent flavours of GHC (not 8.4.1)

See

• https://github.com/haskell/haskell-ide-engine/blob/master/stack-8.0.2.yaml
• https://github.com/haskell/haskell-ide-engine/blob/master/stack-8.2.1.yaml
• https://github.com/haskell/haskell-ide-engine/blob/master/stack.yaml

[infinity0]

The gh802 branch needs further changes for GHC 8.2.2, something to do with transformers-compat:

ghc-mod$ cabal install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: ghc-8.2.2/installed-8.2... (dependency of ghc-mod-5.9.0.0)
next goal: transformers-compat (dependency of exceptions-0.8.3)
rejecting: transformers-compat-0.5.1.4/installed-5tm... (conflict: ghc =>
transformers==0.5.2.0/installed-0.5..., transformers-compat =>
transformers==0.5.5.0/installed-1bb...)
trying: transformers-compat-0.6.0.6
trying: transformers-compat-0.6.0.6:-two
trying: transformers-compat-0.6.0.6:-three
trying: transformers-compat-0.6.0.6:+mtl
rejecting: transformers-compat-0.6.0.6:-five (conflict: ghc =>
transformers==0.5.2.0/installed-0.5..., transformers-compat-0.6.0.6:five =>
transformers>=0.4.1 && <0.5 || >=0.3 && <0.4 || >=0.2 && <0.3 || >=0.5.3 &&
<0.6)
rejecting: transformers-compat-0.6.0.6:+five (manual flag can only be changed
explicitly)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: ghc-mod, ghc-mod-core
Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
exit code 1

[DanielG]

@infinity0 we've split ghc-mod into two packages in that branch now, you need to install ghc-mod-core seperately or use cabal sandbox add-source ./core if you use sandboxes. With cabal new-build it just works FYI but there isn't a new-install yet.

The error message is quite unhelpful unfortunately, I was quite confused too when I saw it.

[infinity0]

Thanks, add-source in a new sandbox worked for me.

In terms of running it in emacs, 'haskell-process-load-file keeps failing with Unexpected response from haskell process. after the last file gets compiled and then some stuff like 'haskell-mode-jump-to-def fails to work with certain external symbols, but other stuff like C-c C-t is working.

[hasufell]

I can compile ghc-mod on the 802 branch just fine, but when I ghc-mod check something creates a directory ~/.cache/cabal-helper and tries to build that with Cabal-2.2.0.1, which then fails, although cabal-helper is already installed in the user-wide db with Cabal-1.24.2.0. I have no idea why ghc-mod is trying to compile dependencies at runtime. What is this?

https://gist.github.com/hasufell/eff8ad280c2ec2538fe488ea489bf136

I can't even edit the file that fails to build, because it is randomly overwritten.

Quite interesting why it's attempting to build against an unsupported Cabal version.

[DanielG]

@hasufell please read cabal-helper's README, it explains why we do this.

The Cabal version number comes from what is in dist/setup-config, you can check it with something like head -n1 dist/setup-config. This is usually the Cabal library version built into your cabal executable. You can check that with cabal --version.

As for how to avoid this compilation, let me quote cabal-helper's output:

If you want to avoid this automatic installation altogether install
version 2.2.0.1 of Cabal manually (into your user or global package-db):
    $ cabal install Cabal --constraint "Cabal == 2.2.0.1"

[hasufell]

As for how to avoid this compilation, let me quote cabal-helper's output:

Cabal doesn't fail to build. cabal-helper does, because it's still built against an incompatible version of Cabal.

I followed the suggestion from cabal-helper output and this is what I get:

$ ghc-mod check Prepare.hs 
[1 of 4] Compiling CabalHelper.Shared.Sandbox ( /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/Sandbox.hs, /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/Sandbox.o )
[2 of 4] Compiling CabalHelper.Shared.InterfaceTypes ( /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/InterfaceTypes.hs, /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/InterfaceTypes.o )
[3 of 4] Compiling CabalHelper.Shared.Common ( /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/Common.hs, /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/Common.o )
[4 of 4] Compiling Main             ( /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Runtime/Main.hs, /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/Main.o )

/home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Runtime/Main.hs:47:1: error:
    Failed to load interface for ‘Distribution.PackageDescription.Parse’
    It is a member of the hidden package ‘Cabal-1.24.2.0’.
    Use -v to see a list of the files searched for.
ghc-mod: readCreateProcess: /home/hasufell/git/ghc-mod2/.cabal-sandbox/libexec/x86_64-linux-ghc-8.0.2.20170314/cabal-helper-0.8.0.2/x86_64-linux-ghc-8.0.2.20170314/cabal-helper-0.8.0.2/cabal-helper-wrapper "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" "/home/hasufell/git/haskell-prepare" "/home/hasufell/git/haskell-prepare/dist" "package-db-stack" "flags" "compiler-version" "ghc-merged-pkg-options" "config-flags" "non-default-config-flags" "ghc-src-options" "ghc-pkg-options" "ghc-lang-options" "ghc-options" "source-dirs" "entrypoints" "needs-build-output" (exit 1): failed

As you can see, the result is completely unchanged. Also see: https://github.com/DanielG/cabal-helper/pull/51

The logic still seems broken. The cabal definition from here https://github.com/DanielG/cabal-helper/blob/master/cabal-helper.cabal#L148 seems to not apply properly

[DanielG]

Ah, indeed. I overlooked that. The runtime compilation doesn't go through cabal for various reasons, so the cabal file just doesn't apply there. We could quite easily compile-in the version bounds and check them at runtime though.

[hasufell]

We could quite easily compile-in the version bounds and check them at runtime though.

I haven't had a look at the code yet that does that, but we don't want it to just say whether the right version exists, but pick the right version based on Cabal < 2.1 && >= 2.0 || < 1.26 && >= 1.14. In this case, it should have picked Cabal-1.24.2.0, which existed.

Or... do we want to fail hard if the requested version that matches the cabal-install binary cannot be satisfied?

[gilligan]

@mrkgnao @jwiegley could either of you possibly provide a working overlay with a ghc-mod that works for 8.2 ? That would be really great..

[DanielG]

@hasufell we have to fail hard. The version we get is dictated by the cabal executable version the user used when running cabal configure (or something that does that internally like cabal build). We can't change that version.

The usual way this sort of situation happens is the user upgrading/reinstalling cabal-install without also upgrading cabal-helper. So we should throw a helpful error explaining the situation and how to uprgade. Not much else we can do really given the position of cabal-helper in the API.

If you'd like to tackle this and have further questions, which I'd be happy to answer, I'd suggest you open an issue over at https://github.com/DanielG/cabal-helper so we can de-noise this thread :)

[infinity0]

Since #909 was closed in favor of this issue, I'll report it here: ghc802 branch fails with cabal version 2 with cabal: The 'repl' command does not support multiple targets at once., see haskell/cabal#4602 for more details.

[DanielG]

@infinity0 the issue you refer to talks about cabal repl how exactly is that related to building ghc-mod? If you want to use the repl just specify which component you want like for example: cabal repl lib for the library component.

[jwiegley]

@gilligan I haven't been using ghc-mod, so I have no working Nix expression for you yet.

[infinity0]

@DanielG my mistake, I thought ghc-mod was responsible for it but I was referring to haskell-mode's "interactive mode" which runs cabal repl. I am probably using an old version too, the one from Debian's package repository.

[drvink]

I'm absolutely boggled as to why there's no mention in this thread that haskell-ide-engine works with GHC 8.2.x and 8.4.x, especially given that it uses ghc-mod as a backend.

[OlivierSohn]

@drvink After reading your comment I tried haskell-ide-engine, unfortunately I ran into this error : it seems multi-project support is not there yet!

[Cypher1]

Also having trouble with ghc-8.2.2. Fresh install of haskell-stack (via brew) fails to stack install ghc-mod

With error here: https://pastebin.com/YS2GUt6n Including the line: ghc-8.2.2 from stack configuration does not match >=7.6 && <8.2

[hasufell]

I'm absolutely boggled as to why there's no mention in this thread that haskell-ide-engine works with GHC 8.2.x and 8.4.x, especially given that it uses ghc-mod as a backend.

It doesn't have one of the most fundamental features, which is "show me the type of an arbitrary expression". Until that it isn't really usable.

[olynch]

is this likely to happen any time soon, given that this issue has been open for a year and the last commit on this repo was in january?

[GoNZooo]

It doesn't have one of the most fundamental features, which is "show me the type of an arbitrary expression". Until that it isn't really usable.

It does. With the VS Code plugin you can mark any given sub-expression and get the type for it ("on hover"). How to plug into that with, for example, the neovim language client is a mystery, because while you can call hover on a visual selection it fails when getting the documentation for that selection and doesn't continue after.

So I would consider this not working a client issue, not an issue with HIE.

[likesalmon]

For Haskell beginners like me who found this thread while attempting to get ghc-mod editor extensions to work (like Haskell ghc-mod for vscode) but maybe don't need the latest and greatest, downgrading to the previous Stackage snapshot worked like a charm. The stackage home page says the previous LTS release is 9.21, so I changed line 21 in stack.yaml to:

resolver: lts-9.21

and ran $ stack setup to install the snapshot. The ghc-mod build succeeded after that:

$ stack build ghc-mod

Then I added this line to my user settings in vscode:

"haskell.ghcMod.executablePath": "stack",

and reloaded the editor. Success!

The Using with stack section of the Atom Haskell docs was helpful.

[Aphexus]

I'll check back in a year...

[pjgoodall]

default.nix.txt nix-trace.txt

This is a total disaster for any beginner trying to use Haskell with atom and stack. I lost half a day trying to work out what I did wrong. I've learned way too much about nix, stack and Atom, and still I can't get a basic IDE which would be expected in any other language community. I shouldn’t have to know ghc-mod even exists.

For new users - the defaults must behave well for a beginner. How can a configuration marked LTS be released if stack build ghc-mod doesn’t execute without error in a default configuration?

This must work: https://atom.io/packages/atom-haskell

[tsabirgaliev]

@pjgoodall, for now the options are:

1. use vscode
2. stick to GHC 8.0 or older

And no need for rage :), this is documented in atom-haskell official docs:

Please bear in mind that official release ghc-mod v5.8.0.0 doesn’t support GHC 8.2. If installing GHC separately, make sure to get GHC 8.0, otherwise, you might run into problems.