A library for building Haskell IDE tooling
Go to file
Jacek Generowicz a162e81aa3 Defer type errors (#47)
* TEST: Degrade type error to warning

It will be upgraded again later, but for the time being we want to see
whether the proposed mechanism for deferring type errors works at
all. As it turns out the first, most obvious approach, does not
work: this is documented in the next commit.

A second approach was found that does work, and appears in the commit
after the next.

This test is failing until the second approach is implemented.

* Defer type errors (first approach: FAILED)

The idea is to set the `-fdefer-type-errors` and
`-fwarn-deferred-type-errors` flags, by setting options
programatically inside the `Ghc` monad.

Deferral of type errors was not observed with this approach. The
(less obvious) approach used in the next commit seems to be more
successful.

* Defer type errors (second approach: SUCCESS)

This approach modifies the `ParsedModule` which is passed to
`GHC.typecheckedModule` by hie-core's `typecheckModule`.

Type warning deferral is now observed at run time, and the tests pass.

* TEST: Reinstate severity of type errors

So far, type errors have been deferred and reported as warnings.

The next step is to ensure that the deferred type errors are reported
as errors rather than warnings, once again. This test fails until the
implementation arrives in the next commit.

* Upgrade severity of deferred Type Errors after typecheck

... and make the test pass again.

* Hide helper functions in local scopes

* Stop setting Opt_WarnDeferredTypeErrors

... and the tests still pass, thereby confirming @hsenag's hypothesis
that this flag is not needed.

* TEST: Check that typed holes are reported as errors

* TEST: Downgrade severity of typed holes Error -> Warning

This test fails, thereby falsifying the hypothesis that
`Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`.

* Defer typed holes

... and pass the failing test.

* TEST: Reinstate severity of typed holes

... failing the test until the implementation catches up in the next
commit.

* Upgrade severity of deferred Typed Holes after typecheck

... and pass the test once again.

* TEST: Degrade variable out of scope from Error to Warning

... test fails until next commit.

* Defer out of scope variables

... passing the test which was changed in the last commit.

* TEST: Reinstate severity of out of scope variables

... failing the test, and forcing the implementation to catch up.

* Upgrade severity of deferred out of scope vars after typecheck

... passing the test once again.

* Add explicit tests for deferrals

* Add IdeOption for deferral switching

* Improve documentation of optDefer

* Add IdeDefer newtype
2019-09-17 14:28:20 +02:00
cbits update copyright notices (#2499) 2019-09-10 14:52:17 +02:00
exe Build on GHC 8.8 (#43) 2019-09-16 15:20:48 +02:00
extension migrate to new @types/vscode, add vsce devDependency 2019-09-13 13:16:38 +02:00
img Make the README a little prettier (#1949) 2019-09-10 14:52:17 +02:00
include Cleanup GHC API version checks 2019-09-16 11:34:25 +02:00
src/Development/IDE Defer type errors (#47) 2019-09-17 14:28:20 +02:00
test Defer type errors (#47) 2019-09-17 14:28:20 +02:00
.ghci Add a .ghci file, was removed in the renaming to ghcide 2019-09-11 09:05:15 +01:00
.gitignore Enable HLint 2019-09-10 16:31:43 +02:00
.hlint.yaml Fix hlint cpp includes (#76) 2019-09-16 17:19:58 +02:00
azure-pipelines.yml Enable more warnings for the ghcide codebase (#75) 2019-09-17 08:50:20 +02:00
fmt.sh Enable HLint 2019-09-10 16:31:43 +02:00
ghcide.cabal Enable more warnings for the ghcide codebase (#75) 2019-09-17 08:50:20 +02:00
hie.yaml hie-core: Ignore packages that conflict with ghc in the hie.yaml (#2819) 2019-09-10 14:52:17 +02:00
install.bat Rename hie-core to ghcide (#2820) 2019-09-10 15:01:29 +02:00
LICENSE add CI config after extraction 2019-09-10 15:40:52 +02:00
README.md Add section on history and relationship to other IDE's (#78) 2019-09-17 08:52:58 +02:00
stack84.yaml Build on GHC 8.8 (#43) 2019-09-16 15:20:48 +02:00
stack-ghc-lib.yaml Build on GHC 8.8 (#43) 2019-09-16 15:20:48 +02:00
stack.yaml Build on GHC 8.8 (#43) 2019-09-16 15:20:48 +02:00

ghcide - A library for building Haskell IDE tooling

Note: ghcide was previously called hie-core.

Our vision is that you should build an IDE by combining:

  • hie-bios for determining where your files are, what are their dependencies, what extensions are enabled and so on;
  • ghcide (i.e. this library) for defining how to type check, when to type check, and producing diagnostic messages;
  • A bunch of plugins that haven't yet been written, e.g. hie-hlint and hie-ormolu, to choose which features you want;
  • haskell-lsp for sending those messages to a Language Server Protocol (LSP) server;
  • An extension for your editor. We provide a VS Code extension as extension in this directory, although the components work in other LSP editors too (see below for instructions using Emacs).

There are more details about our approach in this blog post.

Features

ghcide already exports the following features via the lsp protocol:

  • Display error messages (parse errors, typecheck errors, etc.) and enabled warnings.
  • Offer quickfix for unused imports.
  • Go to definition in local package.
  • Display definitions.
  • Organize imports.

Using it

Install ghcide

With Nix

See hie-core-nix repository

With Cabal or Stack

First install the ghcide binary using stack or cabal, e.g.

  1. git clone https://github.com/digital-asset/ghcide.git
  2. cd ghcide
  3. cabal install or stack install (and make sure ~/.local/bin is on your $PATH)

It's important that ghcide is compiled with the same compiler you use to build your projects.

Test ghcide

Next, check that ghcide is capable of loading your code. Change to the project directory and run ghcide, which will try and load everything using the same code as the IDE, but in a way that's much easier to understand. For example, taking the example of shake, running ghcide gives some error messages and warnings before reporting at the end:

Files that worked: 152
Files that failed: 6
 * .\model\Main.hs
 * .\model\Model.hs
 * .\model\Test.hs
 * .\model\Util.hs
 * .\output\docs\Main.hs
 * .\output\docs\Part_Architecture_md.hs
Done

Of the 158 files in Shake, as of this moment, 152 can be loaded by the IDE, but 6 can't (error messages for the reasons they can't be loaded are given earlier). The failing files are all prototype work or test output, meaning I can confidently use Shake.

The ghcide executable mostly relies on hie-bios to do the difficult work of setting up your GHC environment. If it doesn't work, see the hie-bios manual to get it working. My default fallback is to figure it out by hand and create a direct style hie.yaml listing the command line arguments to load the project.

Once you have got ghcide working outside the editor, the next step is to pick which editor to integrate with.

Using with VS Code

Install the VS code extension (see https://code.visualstudio.com/docs/setup/mac for details on adding code to your $PATH):

  1. cd extension/
  2. npm ci
  3. npm run vscepackage
  4. code --install-extension ghcide-0.0.1.vsix

Now opening a .hs file should work with ghcide.

Using with Emacs

If you don't already have MELPA package installation configured, visit MELPA getting started page to get set up. Then, install use-package. Finally, add the following lines to your .emacs.

;; LSP
(use-package flycheck
  :ensure t
  :init
  (global-flycheck-mode t))
(use-package yasnippet
  :ensure t)
(use-package lsp-mode
  :ensure t
  :hook (haskell-mode . lsp)
  :commands lsp)
(use-package lsp-ui
  :ensure t
  :commands lsp-ui-mode)
(use-package lsp-haskell
 :ensure t
 :config
 (setq lsp-haskell-process-path-hie "ghcide")
 (setq lsp-haskell-process-args-hie '())
 ;; Comment/uncomment this line to see interactions between lsp client/server.
 ;;(setq lsp-log-io t)
)

Using with Vim/Neovim

LanguageClient-neovim

Install LanguageClient-neovim

Add this to your vim config:

let g:LanguageClient_rootMarkers = ['*.cabal', 'stack.yaml']
let g:LanguageClient_serverCommands = {
    \ 'rust': ['rls'],
    \ 'haskell': ['ghcide', '--lsp'],
    \ }

Refer to :he LanguageClient for more details on usage and configuration.

vim-lsp

Install vim-lsp.

Add this to your vim config:

au User lsp_setup call lsp#register_server({
    \ 'name': 'ghcide',
    \ 'cmd': {server_info->['/your/path/to/ghcide', '--lsp']},
    \ 'whitelist': ['haskell'],
    \ })

To verify it works move your cursor over a symbol and run :LspHover.

coc.nvim

Install coc.nvim

Add this to your coc-settings.json (which you can edit with :CocConfig):

{
  "languageserver": {
    "haskell": {
      "command": "ghcide",
      "args": [
        "--lsp"
      ],
      "rootPatterns": [
        ".stack.yaml",
        ".hie-bios",
        "BUILD.bazel",
        "cabal.config",
        "package.yaml"
      ],
      "filetypes": [
        "hs",
        "lhs",
        "haskell"
      ]
    }
  }
}

Here's a nice article on setting up neovim and coc: Vim and Haskell in 2019

History and relationship to other Haskell IDE's

The code behind ghcide was originally developed by Digital Asset as part of the DAML programming language. DAML is a smart contract language targeting distributed-ledger runtimes, based on GHC with custom language extensions. The DAML programming langauge has an IDE, and work was done to separate off a reusable Haskell-only IDE (what is now ghcide) which the DAML IDE then builds upon. Since that time, there have been various non-Digital Asset contributors, in addition to continued investment by Digital Asset.

The Haskell community has various IDE choices, but the one that has been gathering momentum is haskell-ide-engine. Our project owes a debt of gratitude to the haskell-ide-engine. We reuse libraries from their ecosystem, including hie-bios (a likely future environment setup layer in haskell-ide-engine), haskell-lsp and lsp-test (the haskell-ide-engine LSP protocol pieces). We make heavy use of their contributions to GHC itself, in particular the work to make GHC take string buffers rather than files. While ghcide is not a part of haskell-ide-engine, we feel it could form the core of a future version - but such decisions are up to the haskell-ide-engine contributors.

The best summary of the architecture of ghcide is available this talk (slides), given at MuniHac 2019. However, since that talk the project has renamed from hie-core to ghcide, and the repo has moved to this location.