Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
License: Apache License 2.0
The official Haskell language server (LSP) implementation. Consult the project documentation for more details.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
At the moment if I open a big tree in VS Code, then hie-core needs a single HscEnv for interpreting it all. Taking the example of my home directory, I have a folder for extra, one for shake, one for hie-core etc and there is no compatible HscEnv that will answer all their needs. In my view, the only way to solve that is to provide different HscEnv values per file. And if you do that, then you need to share HscEnv values and stop projects cross-importing between HscEnv. Additionally projects don't declare their "root set" of modules, which makes refactors and references way harder. To that end, I propose the API for hie-core:
fileToHscEnvKey :: FilePath -> Action String - given a file, return a key that describes how to build an Env for it. Importantly, many files may return the same key - in fact, every file in a project is expected to return the same key.hscEnvFromKey :: String -> Action (HscEnv, [Either FilePath ModuleName]) - given a key, create an HscEnv and the list of modules/files that should be considered the roots from which all modules can be found.The current hie-bios implementation would return the same "" key for all files and always return the same HscEnv. I think this is the morally correct API from the point of view of hie-core, although happy to discuss the details, since I want to implement it this weekend. I also plan to speak to hie-bios people to see if we can adjust the API towards this one, but even if not, I think it's worth us chasing the right API.
it probably does not yet parse .lhs files
what is the easiest way to get this done?
ghc or lhs2tex as preprocessors?
Not sure what I can do to help with this, the codebase is proprietary, but I may be able to give you private access to it. My working directory has 1228 .hs files. ghcide (run from my shell) makes a lot of progress, and then gets killed as it runs out of memory (at approx. 6.2GB resident memory usage).
This should be a fairly easy beginner task, at least to stop the incorrect action from being shown.
If you have a redundant symbol imported from a module where the module is still needed, e.g. the obvious code generating this error:
C:\msys64\home\ganesh\temp\x\Bar.hs:3:1: warning:
The import of `func3' from module `Foo' is redundant
Then the code action suggests deleting the entire import of Foo, which is wrong.
The simplest fix would be to simply tighten up the recognition here.
But ideally we'd instead get the appropriate action in this case, namely to just delete the unused symbols. That would probably be tricky to get perfect, because of things like data constructors imported with a type etc, but at least some simple cases could be covered. It might involve making a rudimentary effort to parse the import declaration.
It would also be good to have some tests of this action. There weren't any tests of code actions when it was initially written, but there are some now, here.
In my codebase, I have both resource-pool and ex-pool, but we only really use ex-pool. I've tried:
cradle:
direct:
arguments:
- -Wall
- -fno-warn-orphans
- -hide-package resource-pool-0.2.3.2but I get:
File: ./src/Project/Fork.hs
Range: 32:38-32:47
Source: not found
Severity: DsError
Message:
Could not find module ‘Data.Pool’
Perhaps you meant
Data.Pool (from ex-pool-0.2.1)
Data.Pool (needs flag -package-key resource-pool-0.2.3.2)
Data.Bool (from base-4.12.0.0)
Any idea what I'm missing?
I'm not entirely sure if the VS code plugin is responsible here, but the color of the squiggly lines doesn't seem to respect configuration settings. If I set
"workbench.colorCustomizations": {
"editorWarning.foreground": "#ffff00",
"editorWarning.border": "#ffffff"
},
in my configuration file, they still appear in the old color. (The above would be very ugly, I was merely trying to change it at all :).
Hi, cheers for the wonderful keynote at MuniHac. I tried using hie-core on a sample project generated with cabal, and then on hie-core's own source. The former works, the latter doesn't. Poking around I found that the difference is in *hie-stderr*. In the sample project I have:
Starting hie-core
/home/carlo/code/haskell/first
Starting LSP server...
Started LSP server in 0.00s
[DEBUG] Set files of interest to: [NormalizedFilePath "/home/carlo/code/haskell/first/src/First.hs"]
[DEBUG] Starting shakeRun (aborting the previous one took 0.00s)
[INFO] Opened text document: file:///home/carlo/code/haskell/first/src/First.hs
#!/usr/bin/env bash
if [ "$1" == "--interactive" ]; then
pwd
echo "$@"
else
ghc "$@"
fi
/home/carlo/code/haskell/first
res
(ExitSuccess,"",["-w","-v0","-fbuilding-cabal-package","-O0","-outputdir","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-odir","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-hidir","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-stubdir","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-i/home/carlo/code/haskell/first/","-i/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-i/home/carlo/code/haskell/first/src","-i/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/autogen","-i/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/global-autogen","-I/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/autogen","-I/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/global-autogen","-I/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-optP-include","-optP/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/autogen/cabal_macros.h","-this-unit-id","first-0.1.0.0-inplace","-hide-all-packages","-Wmissing-home-modules","-no-user-package-db","-package-db","/home/carlo/.cabal/store/ghc-8.6.5/package.db","-package-db","/home/carlo/code/haskell/first/dist-newstyle/packagedb/ghc-8.6.5","-package-db","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/package.conf.inplace","-package-id","base-4.12.0.0","-package-id","lens-4.17.1-5KWPr0cbJPU7JFmHfmTuKl","-XHaskell2010","First","-hide-all-packages"],"")
["-w","-v0","-fbuilding-cabal-package","-O0","-outputdir","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-odir","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-hidir","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-stubdir","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-i/home/carlo/code/haskell/first/","-i/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-i/home/carlo/code/haskell/first/src","-i/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/autogen","-i/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/global-autogen","-I/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/autogen","-I/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/global-autogen","-I/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build","-optP-include","-optP/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/build/autogen/cabal_macros.h","-this-unit-id","first-0.1.0.0-inplace","-hide-all-packages","-Wmissing-home-modules","-no-user-package-db","-package-db","/home/carlo/.cabal/store/ghc-8.6.5/package.db","-package-db","/home/carlo/code/haskell/first/dist-newstyle/packagedb/ghc-8.6.5","-package-db","/home/carlo/code/haskell/first/dist-newstyle/build/x86_64-linux/ghc-8.6.5/first-0.1.0.0/package.conf.inplace","-package-id","base-4.12.0.0","-package-id","lens-4.17.1-5KWPr0cbJPU7JFmHfmTuKl","-XHaskell2010","First","-hide-all-packages"]
40
(["First"],0)
[DEBUG] Finishing shakeRun (took 1.90s, completed)
while in hie-core:
Starting hie-core
/home/carlo/code/haskell/forks/daml
Starting LSP server...
Started LSP server in 0.00s
[DEBUG] Set files of interest to: [NormalizedFilePath "/home/carlo/code/haskell/forks/daml/compiler/hie-core/src/Development/IDE/LSP/CodeAction.hs"]
[DEBUG] Starting shakeRun (aborting the previous one took 0.00s)
[INFO] Opened text document: file:///home/carlo/code/haskell/forks/daml/compiler/hie-core/src/Development/IDE/LSP/CodeAction.hs
res (ExitSuccess,"cat: '': No such file or directory\n",[],"")
[]
0
([],0)
[DEBUG] Finishing shakeRun (took 0.28s, completed)
Obviously the res (ExitSuccess,"cat: '': No such file or directory\n",[],"") part shouldn't happen, but is it an error in my config, or in hie-core itself? What's the proper fix for this?
In VisualStudio code using the ghcide plugin I get this problem at startup
ghcide: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-apple-darwin):
Dynamic linker not initialised
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Looking at the exe/Main.hs the version I am using was built against the head two days ago and
this line seems to be present
initDynLinker env
The problem seems to correct itself after a while -- maybe ghcide --lsp server re-starts itself... any pointers? Could there be multiple copies of ghcide involved? How does this all work if there are different versions of ghc in use in projects?
ghcide runs ok in the (only) project at issue here. I'll see if I can track this down a bit.
Initially, I would just add some sanity check that at least checks that things still build. I probably wouldn’t bother with tests at least for now. We get those once we bump the version in the DAML repo.
The /azp run thing is pretty annoying for contributing. It slows down the time to feedback, introduces a two-touch minimum from DA employees etc. Any reason not to go with standard Appveyor/Travis more like most open source projects? Or Azure nodes not hosted internally?
I know ghcide is quite fast moving at the moment. But while setting up my vim I was wondering if now I have everything working, which could work at the moment.
So I‘d appreciate a short list of language server functionality which is working in ghcide in the README.md. That would be very helpful!
Otherwise: Keep up the good work!
This would avoid a lot of hassle and the environment would certainly agree.
Would it be possible to use a hoogle database when the identifiers are not found inside the current set of modules? That would perfect the user experience for the go-to-definition feature.
With haskell/ghcide#69 merged it should now be possible to offer a code action to deal with the missing signatures warning.
The most simple approach would be to just generate a signature with a typed hole and then let the user use the code action on that one.
A more sophisticated approach would be to fake the typed hole to ghc and then supply the response directly in the code action.
The longer I think about it the better I like the first option, since it gives the user the ability to write an own signature if wished, the other solution actually sounds a bit complex to implement.
In a project I define my own Data.IntMap module which clashes with the one from containers, so I use the following code to import it:
import qualified "this" Data.IntMap as IntMapGHC accepts this as importing the Data.IntMap from the current project, but ghcide complains that it can't find the module Data.IntMap on this line.
To reproduce, either open src/Context.hs from Sixty, or set up a project with e.g. these modules:
Lib.hs:
{-# language PackageImports #-}
module Lib where
import "this" M -- ghcide errors on this lineM.hs
module M whereIt'd be nice if this worked.
Cheers!
This compiler diagnostic could have the obvious code action to add the imported symbol.
C:\msys64\home\ganesh\temp\x\Bar.hs:5:9: error:
* Variable not in scope: thething3
* Perhaps you want to add `thething3' to the import list
in the import of `Foo'
(C:\msys64\home\ganesh\temp\x\Bar.hs:3:1-17).
I think this is probably fairly easy, but as with haskell/ghcide#45, it will require a bit of infrastructure to understand the structure of import lists to be able to edit them. (And it might be hard to preserve the "right" formatting.)
In some cases there's also a suggestion to rename the reference to something that's already in scope (which was implemented in haskell/ghcide#40) and ideally in that case both code actions would be offered.
stack test in compiler/hie-core is flaky and occasionally fails with
introduce syntax error: FAIL (0.12s)
test/src/Development/IDE/Test.hs:57:
Got diagnostics for Uri {getUri = "file://"} but only expected diagnostics for [NormalizedUri "file:///tmp/extra-dir-98959485489765/Testing.hs"] got List [Diagnostic {_range = Range {_start = Position {_line = 0, _character = 0}, _end = Position {_line = 100000, _character = 0}}, _severity = Just DsError, _code = Nothing, _source = Just "compiler", _message = "hie-core: panic! (the 'impossible' happened)\n (GHC version 8.6.5 for x86_64-unknown-linux):\n\tDynamic linker not initialised\n\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n", _relatedInformation = Nothing}]
Is this because it is downloaded in some binary form?
When I open a file in my test-suite which has test-only dependencies (e.g. hspec) which aren't in the library build-depends, ghcide can't find them and just bugs me about the fact that it can't find Test.Hspec.
Is it possible for ghcide to understand the difference? Let me know if there's a config flag I'm missing, this would be a nice feature to have if it doesn't already exist 😄
My current solution is to add the test dependencies to the library while I'm developing, which is obviously a bit of a hack 😬
By default GHC enables some warnings, but not very many. How about enabling -Wunused-binds -Wunused-imports as those are super useful in an IDE for rapid refactoring.
If people agree, we can set these before calling the cradle initialise so people can still turn them off explicitly if they want.
We know it works with GHC 8.4 today, but without CI, that's likely to stop being true relatively quickly.
Probably also want a GHC 8.8 test too.
They currently live in https://github.com/hercules-ci/ghcide-nix, however, this has a drawback that they have to be manually updated and thus can't use just any commit from ghcide and get a binary.
Once Nix files are in place here, I recommend setting up CI to provide binaries for each commit:
Currently ghcide doesn't notice when I update either package.yaml or *.cabal; so I need to restart it, up till now I've been closing and re-opening my editor, but now I just run killall ghcide; it picks up on the changes when it restarts.
It'd be nice if it could detect changes to those files and restart itself automagically.
Thanks for all the work you do!
We sometimes seem to see error messages like the following one
Exception: Error when calling shakeRunDatabase, currently running:
Existing call: shakeRunDatabase
This appears to be triggered by codelens on DAML codebase requests but I highly doubt that it’ specific to this so opening this here rather than on the daml repository.
I haven’t managed to reproduce it so far but I have a suspicion on what is going on:
shakeRun.shakeRun kills the first call in https://github.com/digital-asset/ghcide/blob/eba0185710042976004467d6a8fdb20d8ed6cc57/src/Development/IDE/Core/Shake.hs#L350.shakeRunDatabase.shakeRun interrupts us after spawning the thread but before setting the MVar to the new stop action, so somewhere here https://github.com/digital-asset/ghcide/blob/eba0185710042976004467d6a8fdb20d8ed6cc57/src/Development/IDE/Core/Shake.hs#L362withMVar the original contents will be restored so our stop action now points to the previous action for stopping A which is already dead.duration stop it will therefore continue immediately without waiting for C to die and we run into the issue described by the error message.@ndmitchell Does that sound plausible to you? If so, it seems like we can fix this by masking between the forkFinally and writing the new stop action to the MVar.
hie-bios is now on Hackage. Could we upload hie-core to Hackage too? It would make installation massively simpler. I have a room of people trying to install it, could that be done?
Trying to synthesise one ticket that describes all the TH work. My understanding of the current state is:
The solution is likely to make sure we have compiled the dependencies to bytecode and send them at the linker before type checking a module that uses TH or ANN.
However, we don't have tests for the current state, and it works by luck rather than deliberately.
ghcide reports in the editor:
<command line>: cannot satisfy -package warp-systemd-0.1.0.0
(use -v for more information)
while the terminal is saying:
$ stack build
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for warp-systemd-0.1.0.0:
base-4.12.0.0 from stack configuration does not match >=4.9 && <4.10 (latest matching version is 4.9.1.0)
network-2.8.0.1 from stack configuration does not match >=2.6.3.0 && <2.7 (latest matching version is 2.6.3.6)
needed due to cachix-server-0.1.0.0 -> warp-systemd-0.1.0.0
Some different approaches to resolving this:
I've tried to run ghcide with default stack-based project but failed because of error Inappropriate ioctl for device:
λ stack -v-version
Version 2.1.3, Git revision 0fa51b9925decd937e4a993ad90cb686f88fa282 (7739 commits) x86_64 hpack-0.31.2
λ stack new ghcide-setup
...
λ cd ghcide-setup\
...
λ stack build hie-bios ghcide --copy-compiler-tool
...
λ stack exec ghcide
Starting ghcide (GHC v8.6)
C:\Dev\learning\ghcide-setup
[1/6] Finding hie-bios cradle
Cradle {cradleRootDir = "C:\\Dev\\learning\\ghcide-setup", cradleOptsProg = CradleAction: stack}
[2/6] Converting Cradle to GHC session
#!/usr/bin/env bash
if [ "$1" == "--interactive" ]; then
pwd
echo "$@"
else
ghc "$@"
fi
ghcide.EXE: (ExitFailure 1,"stty: '\1057\1027\1057\8218\1056\176\1056\1029\1056\1169\1056\176\1057\1026\1057\8218\1056\1029\1057\8249\1056\8470 \1056\1030\1056\1030\1056\1109\1056\1169': Inappropriate ioctl for device\n","")
CallStack (from HasCallStack):
error, called at src\HIE\Bios\Cradle.hs:217:18 in hie-bios-0.1.1-BtqPrxfQWIRF4Jj9iic9A:HIE.Bios.CradleThis is probably a good first issue, unless working out exactly to delete proves hard.
If a symbol isn't used and isn't exported, GHC emits this warning.
C:\msys64\home\ganesh\temp\x\Foo.hs:3:1: warning:
Defined but not used: ‘foo’
It'd be great to have a code action to delete it.
Complicating factors:
I'm trying ghcide on just a single Cabal package from our work codebase. I get the following:
6/6] Loading interesting files
[DEBUG] Finishing shakeRun (took 0.00s, exception: thread killed)
[DEBUG] Starting shakeRun (aborting the previous one took 0.00s)
File: ../entities/Model/Progress.hs
Range: 1:0-100001:0
Source: compiler
Severity: DsError
Message:
expectJust getLinkDeps
CallStack (from HasCallStack):
error, called at compiler/utils/Maybes.hs:55:27 in ghc:Maybes
expectJust, called at compiler/ghci/Linker.hs:719:28 in ghc:Linker
File: ../entities/Model/Common.hs
Range: 1:0-100001:0
Source: compiler
Severity: DsError
Message:
expectJust getLinkDeps
CallStack (from HasCallStack):
error, called at compiler/utils/Maybes.hs:55:27 in ghc:Maybes
expectJust, called at compiler/ghci/Linker.hs:719:28 in ghc:Linker
File: ../entities/Model/OctopartV3.hs
Range: 1:0-100001:0
Source: compiler
Severity: DsError
Message:
expectJust getLinkDeps
CallStack (from HasCallStack):
error, called at compiler/utils/Maybes.hs:55:27 in ghc:Maybes
expectJust, called at compiler/ghci/Linker.hs:719:28 in ghc:Linker
File: ../entities/Model/User.hs
Range: 1:0-100001:0
Source: compiler
Severity: DsError
Message:
expectJust getLinkDeps
CallStack (from HasCallStack):
error, called at compiler/utils/Maybes.hs:55:27 in ghc:Maybes
expectJust, called at compiler/ghci/Linker.hs:719:28 in ghc:Linker
[DEBUG] Finishing shakeRun (took 35.84s, completed)
Files that worked: 0
Files that failed: 1
* app/main.hs
Any idea what this expectJust getLinkDeps business is about?
Doesn't work for constructor
Doesn't work for fields
The find-references feature doesn't seem to work right out of the box. What's needed to make this feature work?
Given the file foo.hs containing:
{-# LANGUAGE CPP #-}
#include "file-that-does-not-exist.h"
Running ghcide foo.hs reports:
File: foo.hs
Range: 1:0-100001:0
Source: compiler
Severity: DsError
Message: `gcc.exe' failed in phase `C pre-processor'. (Exit code: 1)
While running ghc foo.hs reports:
foo.hs:3:2: error:
fatal error: file-that-does-not-exist.h: No such file or directory
compilation terminated.
`gcc.exe' failed in phase `C pre-processor'. (Exit code: 1)
The ghc error is super helpful. The ghcide error is just the final and most useless line of that error message. I'm not sure how the useful error ends up on the output (is it just gcc inheriting the console? Or is something smarter happening?) but it would be a significant improvement.
I encountered this issue debugging haskell/ghcide#86 - I had to modify the source of ghcide and run commands manually to figure out what was going on. If I had the above info, it would have taken seconds.
Apologies for the slightly vague bug report, but after spending a little while investigating already, I'd like to get an idea of what's actually supposed to work before digging in more depth.
There's code in Documentation.hs and AtPoint.hs that appears to be intended to include haddock docs in the hover information.
However I never see any, even with really trivial test cases. Is this something that is expected to work or is working for others?
One thing I noticed is that there are references in Documentation.hs to things happening when Opt_Haddock or Opt_KeepRawTokenStream are enabled, but I don't see them enabled anywhere.
I have for example the following situation:
Found type wildcard ‘_’ standing for ‘R.Dynamic t [Task] -> m ()’
Where: ‘t’, ‘m’ are rigid type variables bound by the type signature for: ...
It‘s not an import bug right now, but when t and m are not declared with forall t m and ScopedTypeVariables the inserted signature for the type hole will probably fail because it's lacking all constraints for t and m.
I am not sure what the correct solution is:
As I said this is not urgent and I see that a fix might be hard. Nonetheless I thought having the problem noted somewhere might help.
It seems that hie-core doesn't call type-checker plugin properly.
A complete minimal example is given by the following (you need ghc-typelits-knownnat type-checker plugin and have to add it as a dependency):
{-# LANGUAGE DataKinds, ScopedTypeVariables, TypeOperators #-}
{-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-}
module Main where
import Data.Proxy
import GHC.TypeLits
natPlus1 :: forall n . KnownNat n => Proxy n -> Integer
natPlus1 = const $ natVal (Proxy :: Proxy (n + 1))
main :: IO ()
main = print $ natPlus1 (Proxy :: Proxy 5)The intension here is to use ghc-typelits-knownnat type-checker plugin to automatically derive KnownNat (n + 1) dictionary from KnownNat n.
This program passes the compilation and prints 6 as expected, but if one invokes hie-core in the project-root, it reports the following type-check error:
$ hie-core
Starting hie-core (GHC v8.6)
/path/to/project
[1/6] Finding hie-bios cradle
Cradle {cradleRootDir = "/path/to/project", cradleOptsProg = CradleAction: stack}
...
[5/6] Setting interesting files
[DEBUG] Set files of interest to: [NormalizedFilePath "./Setup.hs",NormalizedFilePath "./src/Main.hs"]
[DEBUG] Starting shakeRun (aborting the previous one took 0.00s)
[6/6] Loading interesting files
[DEBUG] Finishing shakeRun (took 0.00s, exception: thread killed)
[DEBUG] Starting shakeRun (aborting the previous one took 0.00s)
File: ./Setup.hs
Range: 1:7-1:26
Source: not found
Severity: DsError
Message:
Could not load module ‘Distribution.Simple’
It is a member of the hidden package ‘Cabal-2.4.1.0’.
You can run ‘:set -package Cabal’ to expose it.
(Note: this unloads all the modules in the current scope.)
File: ./Setup.hs
File: ./Setup.hs
File: ./Setup.hs
File: ./Setup.hs
Range: 1:7-1:26
Source: not found
Severity: DsError
Message:
Could not load module ‘Distribution.Simple’
It is a member of the hidden package ‘Cabal-2.4.1.0’.
You can run ‘:set -package Cabal’ to expose it.
(Note: this unloads all the modules in the current scope.)
It is a member of the hidden package ‘Cabal-2.4.0.1’.
You can run ‘:set -package Cabal’ to expose it.
(Note: this unloads all the modules in the current scope.)
File: ./src/Main.hs
Range: 8:19-8:50
Source: typecheck
Severity: DsError
Message:
src/Main.hs:8:20: error:
• Could not deduce (KnownNat (n + 1))
arising from a use of ‘natVal’
from the context: KnownNat n
bound by the type signature for:
natPlus1 :: forall (n :: Nat). KnownNat n => Proxy n -> Integer
at src/Main.hs:7:1-55
• In the second argument of ‘($)’, namely
‘natVal (Proxy :: Proxy (n + 1))’
In the expression: const $ natVal (Proxy :: Proxy (n + 1))
In an equation for ‘natPlus1’:
natPlus1 = const $ natVal (Proxy :: Proxy (n + 1))
[DEBUG] Finishing shakeRun (took 0.07s, completed)
Files that worked: 0
Files that failed: 2
* ./Setup.hs
* ./src/Main.hs
Done
I've tested this with LTS-13.6 and hie-core from HEAD.
ghcide executable needs to be compiled with the same matching GHC version.There's missing automation to connect 1 and 2
Create thin ghcide-wrapper that runs hie-bios to get the compiler version and then execute ghcide-X.X.X
~/wrk/haskell-works/hw-bits on master!$ ghcide
Starting ghcide (GHC v8.6)
/Users/jky/wrk/haskell-works/hw-bits
[1/6] Finding hie-bios cradle
Cradle {cradleRootDir = "/Users/jky/wrk/haskell-works/hw-bits", cradleOptsProg = CradleAction: stack}
[2/6] Converting Cradle to GHC session
#!/usr/bin/env bash
if [ "$1" == "--interactive" ]; then
pwd
echo "$@"
else
ghc "$@"
fi
/Users/jky/wrk/haskell-works/hw-bits
res
(ExitSuccess,"",["-i/Users/jky/wrk/haskell-works/hw-bits/","-odir=/Users/jky/wrk/haskell-works/hw-bits/.stack-work/odir","-hidir=/Users/jky/wrk/haskell-works/hw-bits/.stack-work/odir","-hide-all-packages","-i/Users/jky/wrk/haskell-works/hw-bits/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build","-i/Users/jky/wrk/haskell-works/hw-bits/src","-i/Users/jky/wrk/haskell-works/hw-bits/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/autogen","-i/Users/jky/wrk/haskell-works/hw-bits/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/global-autogen","-stubdir=/Users/jky/wrk/haskell-works/hw-bits/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build","-package-id=base-4.11.1.0","-package-id=bytestring-0.10.8.2","-package-id=hw-int-0.0.0.3-CXZpz8J7RAvG52S7XWyEdK","-package-id=hw-prim-0.6.2.17-1Voz5VVZex09AO0Rb46nDq","-package-id=hw-string-parse-0.0.0.4-GZtXcLU1eS2FBFNOYMa3KI","-package-id=vector-0.12.0.1-GGZqQZyzchy8YFPCF67wxL","-Wall","-msse4.2","-optP-include","-optP/Users/jky/wrk/haskell-works/hw-bits/.stack-work/ghci/df9e921b/cabal_macros.h","-package-db","/Users/jky/wrk/haskell-works/hw-bits/.stack-work/install/x86_64-osx/2e49778080877c18fe4b909beb5ae5b29e85cae8d9fecc3243aee9103bce0866/8.4.3/pkgdb","-package-db","/Users/jky/.stack/snapshots/x86_64-osx/2e49778080877c18fe4b909beb5ae5b29e85cae8d9fecc3243aee9103bce0866/8.4.3/pkgdb","-package-db","/Users/jky/.stack/programs/x86_64-osx/ghc-8.4.3/lib/ghc-8.4.3/package.conf.d"],"")
["-i/Users/jky/wrk/haskell-works/hw-bits/","-odir=/Users/jky/wrk/haskell-works/hw-bits/.stack-work/odir","-hidir=/Users/jky/wrk/haskell-works/hw-bits/.stack-work/odir","-hide-all-packages","-i/Users/jky/wrk/haskell-works/hw-bits/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build","-i/Users/jky/wrk/haskell-works/hw-bits/src","-i/Users/jky/wrk/haskell-works/hw-bits/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/autogen","-i/Users/jky/wrk/haskell-works/hw-bits/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/global-autogen","-stubdir=/Users/jky/wrk/haskell-works/hw-bits/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build","-package-id=base-4.11.1.0","-package-id=bytestring-0.10.8.2","-package-id=hw-int-0.0.0.3-CXZpz8J7RAvG52S7XWyEdK","-package-id=hw-prim-0.6.2.17-1Voz5VVZex09AO0Rb46nDq","-package-id=hw-string-parse-0.0.0.4-GZtXcLU1eS2FBFNOYMa3KI","-package-id=vector-0.12.0.1-GGZqQZyzchy8YFPCF67wxL","-Wall","-msse4.2","-optP-include","-optP/Users/jky/wrk/haskell-works/hw-bits/.stack-work/ghci/df9e921b/cabal_macros.h","-package-db","/Users/jky/wrk/haskell-works/hw-bits/.stack-work/install/x86_64-osx/2e49778080877c18fe4b909beb5ae5b29e85cae8d9fecc3243aee9103bce0866/8.4.3/pkgdb","-package-db","/Users/jky/.stack/snapshots/x86_64-osx/2e49778080877c18fe4b909beb5ae5b29e85cae8d9fecc3243aee9103bce0866/8.4.3/pkgdb","-package-db","/Users/jky/.stack/programs/x86_64-osx/ghc-8.4.3/lib/ghc-8.4.3/package.conf.d"]
25
([],0)
ghcide:
lookupSymbol failed in relocateSection (RELOC_GOT)
/Users/jky/.stack/programs/x86_64-osx/ghc-8.4.3/lib/ghc-8.4.3/ghc-prim-0.5.2.0/HSghc-prim-0.5.2.0.o: unknown symbol `_stg_MUT_ARR_PTRS_FROZEN0_info'
ghcide: ghcide: unable to load package `ghc-prim-0.5.2.0'
This is the current implementation of ghcide executable discovery, which is being used to start the LSP server which responds to queries sent by the test suite:
locateGhcideExecutable :: IO FilePath
locateGhcideExecutable = pure "ghcide"
Consequently, the tests end up talking to a server which happens to be on $PATH, rather than the one which is relevant to the configuration currently being tested.
Should be a good first issue if identifying the right bit of code to remove is simple enough (as weith haskell/ghcide#54).
If the -Wredundant-constraints warning is on, GHC emits warnings like:
C:\msys64\home\ganesh\temp\x\Foo.hs:3:1: warning:
• Redundant constraint: Ord a
• In the type signature for:
foo :: forall a. Ord a => a -> Int
Unfortunately the source range covers all of the type signature for foo, not just the redundant constraint itself.
Following MuniHac, a number of people asked questions about the CLA. So the feedback reaches DA, I thought I'd write it here (there may be no actions to take as a result).
You represent that each of Your Contributions is Your original creation. You represent that Your Contribution submissions include complete details of any third-party license or other restriction of which you are personally aware and which are associated with any part of Your Contributions.
But it's quite reasonable to submit third party code to DAML, eg. snippets copied from StackOverflow, provided you represent they are freely licensable as Apache2. If the first full stop is a considered an OR then it's allowed already.
version: 1.28.0-insider (user setup)
commit: 431ef9da3cf88a7e164f9d33bf62695e07c6c2a9
date: 2018-10-03T12:44:29.343Z
Electron: 2.0.9
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64
hie verison: Version 0.2.2.0, Git revision 881f2b3b737c34f72fffa3bec94f08f256f0d6fe (2000 commits) x86_64 ghc-8.4.2
code example:
a::[Int]
a=[x|x<-[1..3]]get output
[Error - 7:19:30 AM] Request textDocument/formatting failed.
Message: brittanyCmd: RealSrcSpan SrcSpanMultiLine "stdin" 2 6 3 1: unterminated quasiquotation at end of input
Code: -32603
but when i use brittany that separately install, no error occurs.(version brittany version 0.9.0.0)
is it a brittany bug? or hie? or vscode-hie-server?
I believe that at least lsp-test is a blocker for now but there is probably tons of other stuff.
If you edit compiler/hie-core/test/exe/Main.hs to make one of the tests
expect no diagnostics, then it hits the base case of Development.IDE.Test.expectDiagnostics and doesn't check that there are actually 0 diagnostics.
I think it's because it just hits the Map.null base case immediately. Also it would go wrong if there are diagnostics for files not listed in the expected list that come at the end of the published diagnostics.
I'm happy to have a go at fixing it myself if someone could confirm my analysis so far is correct.
In what follows, I disable the "fix syntax error test" because it
usually times out on my machine.
The total time taken to execute all tests is slightly misleading,
because more tests (30 vs 28) are executed on 8.6 than on 8.4, but the list of
individual timings makes the issue quite clear.
Here are the GHC 8.4 timings:
$ cabal v2-install exe:ghcide --overwrite-policy=always -w ghc-8.4.4
Wrote tarball sdist to
/home/jacek/src/ghcide/dist-newstyle/sdist/ghcide-0.0.2.tar.gz
Resolving dependencies...
Up to date
Symlinking 'ghcide'
$ cabal v2-run tests -w ghc-8.4.4 -- -p '! /fix syntax error/'
Resolving dependencies...
Up to date
HIE
open close: OK (0.51s)
diagnostics
introduce syntax error: OK (0.62s)
variable not in scope: OK (0.67s)
type error: OK (0.67s)
typed hole: OK (0.82s)
remove required module: OK (0.67s)
add missing module: OK (0.79s)
cyclic module dependency: OK (0.63s)
cyclic module dependency with hs-boot: OK (0.52s)
correct reference used with hs-boot: OK (0.52s)
redundant import: OK (0.66s)
package imports: OK (0.67s)
unqualified warnings: OK (0.72s)
code actions
rename actions
change to local variable name: OK (0.67s)
change to name of imported function: OK (0.68s)
suggest multiple local variable names: OK (0.67s)
change infix function: OK (0.70s)
type wildcard actions
global signature: OK (0.67s)
multi-line message: OK (0.67s)
local signature: OK (0.66s)
remove import actions
redundant: OK (0.67s)
qualified redundant: OK (0.67s)
import rename actions
Data.Mape -> Data.Map: OK (0.65s)
Data.Mape -> Data.Maybe: OK (0.65s)
fill typed holes
replace hole `_` with show: OK (0.85s)
replace hole `_` with globalConvert: OK (0.86s)
replace hole `_b` with globalInt: OK (0.95s)
replace hole `_c` with globalInt: OK (0.93s)
All 28 tests passed (19.41s)
... and here are the timings for GHC 8.6
$ cabal v2-install exe:ghcide --overwrite-policy=always -w ghc-8.6.4
Wrote tarball sdist to
/home/jacek/src/ghcide/dist-newstyle/sdist/ghcide-0.0.2.tar.gz
Resolving dependencies...
Up to date
Symlinking 'ghcide'
$ cabal v2-run tests -w ghc-8.6.4 -- -p '! /fix syntax error/'
Resolving dependencies...
Up to date
HIE
open close: OK (0.52s)
diagnostics
introduce syntax error: OK (1.29s)
variable not in scope: OK (1.37s)
type error: OK (1.33s)
typed hole: OK (1.55s)
remove required module: OK (1.40s)
add missing module: OK (1.48s)
cyclic module dependency: OK (1.30s)
cyclic module dependency with hs-boot: OK (0.53s)
correct reference used with hs-boot: OK (0.53s)
redundant import: OK (1.37s)
package imports: OK (1.38s)
unqualified warnings: OK (1.39s)
code actions
rename actions
change to local variable name: OK (1.33s)
change to name of imported function: OK (1.36s)
suggest multiple local variable names: OK (1.37s)
change infix function: OK (1.36s)
type wildcard actions
global signature: OK (1.34s)
multi-line message: OK (1.33s)
local signature: OK (1.37s)
remove import actions
redundant: OK (1.35s)
qualified redundant: OK (1.34s)
import rename actions
Data.Mape -> Data.Map: OK (1.35s)
Data.Mape -> Data.Maybe: OK (1.39s)
fill typed holes
replace hole `_` with show: OK (1.54s)
replace hole `_` with globalConvert: OK (1.55s)
replace hole `_b` with globalInt: OK (1.72s)
replace hole `_c` with globalInt: OK (1.72s)
replace hole `_convertme` with localConvert: OK (1.59s)
replace hole `_c` with parameterInt: OK (1.67s)
All 30 tests passed (40.13s)
So, typical times for individual tests of 0.6s vs 1.3s, or a total
runtime of 20s vs 40s.
Given that haskell/ghcide@6176093 introduced a 0.5s timeout overhead into each test (as reflected in the timing of the essentially no-op test "open close"), we could actually be looking at a much more significant slow-down factor in code execution.
Perhaps there is something important or interesting behind this.
ghcide gives me information on most alphanumeric symbols (and numeric literals) but there are two features that I'm used to from dante and/or intero:
Do these features exist, and have I simply not found them?
If not, any hints on how to implement them?
I installed hie-core and it works from command line on a given file. I also installed vim-lsp to integrate with neovim and added the configuration line from the README in my init.vim, but when I try :LspHover on a symbol, I get Retrieving hover not supported for haskell. What do I do next?
I am trying to run ghcide from macOS 10.13.6.
Running ghcide in my folder (https://github.com/into-cps-association/utilities_backend) gives me:
Starting ghcide (GHC v8.6)
/Users/casperthule/source/into-cps-association/utilities_backend
[1/6] Finding hie-bios cradle
Cradle {cradleRootDir = "/Users/casperthule/source/into-cps-association/utilities_backend", cradleOptsProg = CradleAction: stack}
[2/6] Converting Cradle to GHC session
#!/usr/bin/env bash
if [ "$1" == "--interactive" ]; then
pwd
echo "$@"
else
ghc "$@"
fi
/Users/casperthule/source/into-cps-association/utilities_backend
res
(ExitSuccess,"",["-i/Users/casperthule/source/into-cps-association/utilities_backend/","-odir=/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/odir","-hidir=/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/odir","-hide-all-packages","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build","-i/Users/casperthule/source/into-cps-association/utilities_backend/src","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-stubdir=/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build","-package-id=base-4.12.0.0","-package-id=bytestring-0.10.8.2","-package-id=directory-1.3.3.0","-package-id=http-types-0.12.3-4L76TmlQodx6G0dPW61wNW","-package-id=process-1.6.5.0","-package-id=scotty-0.11.4-7dU6HeNRGxKEPtHaX4hUiq","-package-id=text-1.2.3.1","-package-id=uuid-1.3.13-LENSHVvURVpDg0jIxM9pjW","-package-id=wai-3.2.2.1-FOZJOUvCRGiBx7sNGMWXUj","-package-id=wai-cors-0.2.7-5afJ9x7Gwrd9rYIhHmJoYF","-package-id=wai-extra-3.0.26.1-FLHy0Enyv1b6APZpqkZUP1","-package-id=wai-middleware-static-0.8.2-P8d2RpygISLRk3U02Lkz2","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/HsBeFMI-exe","-i/Users/casperthule/source/into-cps-association/utilities_backend/app","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/HsBeFMI-exe/autogen","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/HsBeFMI-exe/HsBeFMI-exe-tmp","-rtsopts","-with-rtsopts=-N","-optP-include","-optP/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/ghci/5d489a5f/cabal_macros.h","-package-db","/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/install/x86_64-osx/6e3a712292cd6f9bbf8a37e08822c477ea2f5dd26b42bce53afd84f0b0249f52/8.6.5/pkgdb","-package-db","/Users/casperthule/.stack/snapshots/x86_64-osx/6e3a712292cd6f9bbf8a37e08822c477ea2f5dd26b42bce53afd84f0b0249f52/8.6.5/pkgdb","-package-db","/Users/casperthule/.stack/programs/x86_64-osx/ghc-8.6.5/lib/ghc-8.6.5/package.conf.d"],"")
["-i/Users/casperthule/source/into-cps-association/utilities_backend/","-odir=/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/odir","-hidir=/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/odir","-hide-all-packages","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build","-i/Users/casperthule/source/into-cps-association/utilities_backend/src","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-stubdir=/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build","-package-id=base-4.12.0.0","-package-id=bytestring-0.10.8.2","-package-id=directory-1.3.3.0","-package-id=http-types-0.12.3-4L76TmlQodx6G0dPW61wNW","-package-id=process-1.6.5.0","-package-id=scotty-0.11.4-7dU6HeNRGxKEPtHaX4hUiq","-package-id=text-1.2.3.1","-package-id=uuid-1.3.13-LENSHVvURVpDg0jIxM9pjW","-package-id=wai-3.2.2.1-FOZJOUvCRGiBx7sNGMWXUj","-package-id=wai-cors-0.2.7-5afJ9x7Gwrd9rYIhHmJoYF","-package-id=wai-extra-3.0.26.1-FLHy0Enyv1b6APZpqkZUP1","-package-id=wai-middleware-static-0.8.2-P8d2RpygISLRk3U02Lkz2","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/HsBeFMI-exe","-i/Users/casperthule/source/into-cps-association/utilities_backend/app","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/HsBeFMI-exe/autogen","-i/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/HsBeFMI-exe/HsBeFMI-exe-tmp","-rtsopts","-with-rtsopts=-N","-optP-include","-optP/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/ghci/5d489a5f/cabal_macros.h","-package-db","/Users/casperthule/source/into-cps-association/utilities_backend/.stack-work/install/x86_64-osx/6e3a712292cd6f9bbf8a37e08822c477ea2f5dd26b42bce53afd84f0b0249f52/8.6.5/pkgdb","-package-db","/Users/casperthule/.stack/snapshots/x86_64-osx/6e3a712292cd6f9bbf8a37e08822c477ea2f5dd26b42bce53afd84f0b0249f52/8.6.5/pkgdb","-package-db","/Users/casperthule/.stack/programs/x86_64-osx/ghc-8.6.5/lib/ghc-8.6.5/package.conf.d"]
35
([],0)
[3/6] Initialising IDE session
[4/6] Finding interesting files
Found 4 files
[5/6] Setting interesting files
[DEBUG] Set files of interest to: [NormalizedFilePath "./Setup.hs",NormalizedFilePath "./app/Main.hs",NormalizedFilePath "./src/Lib.hs",NormalizedFilePath "./test/Spec.hs"]
[DEBUG] Starting shakeRun (aborting the previous one took 0.00s)
[6/6] Loading interesting files
[DEBUG] Finishing shakeRun (took 0.00s, exception: thread killed)
[DEBUG] Starting shakeRun (aborting the previous one took 0.00s)
File: ./Setup.hs
Range: 1:7-1:26
Source: not found
Severity: DsError
Message:
Could not load module ‘Distribution.Simple’
It is a member of the hidden package ‘Cabal-2.4.1.0’.
You can run ‘:set -package Cabal’ to expose it.
(Note: this unloads all the modules in the current scope.)
It is a member of the hidden package ‘Cabal-2.4.0.1’.
File: ./Setup.hs
Range: 1:7-1:26
Source: not found
Severity: DsError
Message:
Could not load module ‘Distribution.Simple’
It is a member of the hidden package ‘Cabal-2.4.1.0’.
You can run ‘:set -package Cabal’ to expose it.
(Note: this unloads all the modules in the current scope.)
It is a member of the hidden package ‘Cabal-2.4.0.1’.
You can run ‘:set -package Cabal’ to expose it.
(Note: this unloads all the modules in the current scope.)
[DEBUG] Finishing shakeRun (took 1.00s, completed)
Files that worked: 3
Files that failed: 1
* ./Setup.hs
Done
Can someone assist with what I am missing?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.