在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):haskell/ghcide开源软件地址(OpenSource Url):https://github.com/haskell/ghcide开源编程语言(OpenSource Language):Haskell 99.0%开源软件介绍(OpenSource Introduction):MovedThis project is now a historical artifact. It has been merged and all issues transferred into: https://github.com/haskell/haskell-language-server
|
Feature | LSP name |
---|---|
Display error messages (parse errors, typecheck errors, etc.) and enabled warnings. | diagnostics |
Go to definition in local package | definition |
Display type and source module of values | hover |
Remove redundant imports, replace suggested typos for values and module imports, fill type holes, insert missing type signatures, add suggested ghc extensions | codeAction (quickfix) |
ghcide
supports loading multiple components into the same session so that
features such as go-to definition work across components. However, there are
some limitations to this.
ghcide
is not an end-user tool, don't use ghcide
directly (more about the rationale here).
haskell-language-server
is an LSP server built on top of ghcide
with additional features and a user friendly deployment model. To get it, simply install the Haskell extension in VS Code, or download prebuilt binaries from the haskell-language-server project page.
The instructions below are meant for developers interested in setting up ghcide as an LSP server for testing purposes.
ghcide
Note that you need to compile ghcide
with the same ghc
as the project you are working on.
If the ghc
you are using matches the version (or better is) from nixpkgs
it‘s easiest to use the ghcide
from nixpkgs
. You can do so via
nix-env -iA haskellPackages.ghcide
or e.g. including pkgs.haskellPackages.ghcide
in your projects shell.nix
.
Depending on your nixpkgs
channel that might not be the newest ghcide
, though.
If your ghc
does not match nixpkgs you should try the ghcide-nix repository
which provides a ghcide
via the haskell.nix
infrastructure.
First install the ghcide
binary using stack
or cabal
, e.g.
git clone https://github.com/haskell/ghcide.git
cd ghcide
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.
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 failed:
* .\model\Main.hs
* .\model\Model.hs
* .\model\Test.hs
* .\model\Util.hs
* .\output\docs\Main.hs
* .\output\docs\Part_Architecture_md.hs
Completed (152 worked, 6 failed)
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.
If you can't get ghcide
working outside the editor, see this setup troubleshooting guide. Once you have got ghcide
working outside the editor, the next step is to pick which editor to integrate with.
ghcide
has been designed to handle projects with hundreds or thousands of modules. If ghci
can handle it, then ghcide
should be able to handle it. The only caveat is that this currently requires GHC >= 8.6, and that the first time a module is loaded in the editor will trigger generation of support files in the background if those do not already exist.
ghcide
accepts the following lsp configuration options:
{
// When to check the dependents of a module
// AlwaysCheck means retypechecking them on every change
// CheckOnSave means dependent/parent modules will only be checked when you save
// "CheckOnSaveAndClose" by default
checkParents : "NeverCheck" | "CheckOnClose" | "CheckOnSaveAndClose" | "AlwaysCheck" | ,
// Whether to check the entire project on initial load
// true by default
checkProject : boolean
}
The Haskell extension has a setting for ghcide.
You can follow the instructions to install with apm
.
{
"clients":
{
"ghcide":
{
"enabled" : true,
"languageId": "haskell",
"command" : ["ghcide", "--lsp"],
"scopes" : ["source.haskell"],
"syntaxes" : ["Packages/Haskell/Haskell.sublime-syntax"]
}
}
}
If you don't already have MELPA package installation configured, visit MELPA getting started page to get set up. Then, install use-package
.
Now you have a choice of two different Emacs packages which can be used to communicate with the ghcide
LSP server:
lsp-ui
eglot
(requires Emacs 26.1+)In each case, you can enable support by adding the shown 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)
)
(use-package eglot
:ensure t
:config
(add-to-list 'eglot-server-programs '(haskell-mode . ("ghcide" "--lsp"))))
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.
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
.
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 (this is actually for haskell-ide, not ghcide)
Here is a Docker container that pins down the build and configuration for Neovim and ghcide on a minimal Debian 10 base system: docker-ghcide-neovim.
In the autocomplete
layer, add the autocomplete_method
option to force the use of coc
:
[[layers]]
name = 'autocomplete'
auto-completion-return-key-behavior = "complete"
auto-completion-tab-key-behavior = "smart"
[options]
autocomplete_method = "coc"
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"
]
}
}
}
This example above describes a setup in which ghcide
is installed
using stack install ghcide
within a project.
Install kak-lsp.
Change kak-lsp.toml
to include this:
[language.haskell]
filetypes = ["haskell"]
roots = ["Setup.hs", "stack.yaml", "*.cabal", "cabal.project", "hie.yaml"]
command = "ghcide"
args = ["--lsp"]
To build and work on ghcide
itself, you should use cabal, e.g.,
running cabal test
will execute the test suite. You can use stack test
too, but
note that some tests will fail, and none of the maintainers are currently using stack
.
If you are using Nix, there is a Cachix nix-shell cache for all the supported platforms: cachix use haskell-ghcide
.
If you are using Windows, you should disable the auto.crlf
setting and configure your editor to use LF line endings, directly or making it use the existing .editor-config
.
If you are chasing down test failures, you can use the tasty-rerun feature by running tests as
cabal test --test-options"--rerun"
This writes a log file called .tasty-rerun-log
of the failures, and only runs those.
See the tasty-rerun documentation for other options.
If you are touching performance sensitive code, take the time to run a differential benchmark between HEAD and master using the benchHist script. This assumes that "master" points to the upstream master.
Run the benchmarks with cabal bench
.
It should take around 15 minutes and the results will be stored in the bench-results
folder. To interpret the results, see the comments in the bench/hist/Main.hs
module.
More details in bench/README
The teams behind this project and the haskell-ide-engine
have agreed to join forces under the haskell-language-server
project, see the original announcement. The technical work is ongoing, with the likely model being that this project serves as the core, while plugins and integrations are kept in the haskell-language-server
project.
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 language 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 project has been handed over to Haskell.org as of September 2020.
The Haskell community has various IDE choices, but the one that had 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.
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.
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论