ehmry/dhall-haskell
ehmry/dhall-haskell
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
66833cbfa5
dhall-haskell/dhall-lsp-server/dhall-lsp-server.cabal

142 lines
3.3 KiB
Plaintext
Raw Normal View History

Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
cabal-version: 1.12
name: dhall-lsp-server
[LSP] add basic formatting (#844)
2019-03-08 15:24:54 +01:00
version: 0.1.0.1
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
description: Please see the README on GitHub at <https://github.com/githubuser/dhall-lsp-server#readme>
homepage: https://github.com/dhall-lang/dhall-haskell/dhall-lsp-server#readme
bug-reports: https://github.com/dhall-lang/dhall-haskell/issues
author: panaeon
maintainer: panaeon
copyright: 2019 panaeon
license: MIT
license-file: LICENSE
build-type: Simple
extra-source-files:
README.md
ChangeLog.md
source-repository head
type: git
location: https://github.com/dhall-lang/dhall-haskell
library
exposed-modules:
dhall-lsp-server: Towards implementing a "convert to JSON" command (#1005) At the moment the VSCode plugin contains a hacked-together prototype of a dhall-to-json (and -to-yaml) preview feature. We should ultimately move that kind of functionality to dhall-lsp-server to 1) minimise the amount of VSCode specific code and 2) avoid having to work with and fix bugs in typescript code ;) This commit takes us most of the way there; what is missing is the ability to create files (via a WorkspaceEditRequest), which is not yet implemented by haskell-lsp-types. I will wait with exposing the corresponding command (and removing the existing preview code) in vscode-dhall-lsp-server until this is fixed upstream.
2019-06-13 16:23:48 +02:00
Dhall.LSP.Backend.Dhall
Simplify dhall-lsp-server and reorganise its modules (#992) * Clean up dhall-lsp-server's Main.hs Also adds haddock comments. * Remove TODO comment The comment talks about adding a mechanism for protocol-level logging to dhall-lsp-server. Since the VSCode LSP implementation has this feature already baked in on the client side, we don't have to implement it ourselves. * Simplify dhall-lsp-server's infrastructure So far we had a system where we set up the LSP message handlers to relay messages to a separate dispatcher thread via a shared channel. Since our language server is at the same time designed in a completely synchronous manner, this complication turns out to be unnecessary. * Remove sample code * Fix unused variable warning * Reorganise dhall-lsp-server's module hierarchy Prefixes all modules with "Dhall.LSP.". Previously: Backend.Dhall. .Diagnostics .Formatting LSP. .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server Now: Dhall.LSP. .Backend. .Diagnostics .Formatting .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server * Make dhall-lsp-server tests compile again They still fail though!
2019-06-07 09:47:07 +02:00
Dhall.LSP.Backend.Diagnostics
Dhall.LSP.Backend.Formatting
dhall-lsp-server: Implement linter diagnostics and "Lint and Format" command (#1003) * Refactor Dhall.LSP.Backend.Formatting Exposes `formatExpr :: Text -> Expr a Import -> Text` that can be reused in the lintAndFormat command. * Implement linting backend in Dhall.LSP.Backend.Linting Exposes `suggest :: Eq a => Expr Src a -> [Suggestion]` and `lintAndFormatDocument :: Text -> Either ParseError Text`. * Fix unusedBindings * Implement linter diagnostics * Improve linting diagnostic ranges In VSCode we now mark the "let" following a superfluous "in". let a = 0 in let b = a in b ~ Previously we got let a = 0 in let b = a in b ~ which was slightly confusing * Implement executeCommand handler for "Lint and Format" This exposes the command "dhall.server.lint", which should be called from the vscode plugin to lint and format the current dhall file. Needs a correspondingly patched vscode-dhall-lsp-server (branch lint).
2019-06-11 17:10:16 +02:00
Dhall.LSP.Backend.Linting
dhall-lsp-server: Towards implementing a "convert to JSON" command (#1005) At the moment the VSCode plugin contains a hacked-together prototype of a dhall-to-json (and -to-yaml) preview feature. We should ultimately move that kind of functionality to dhall-lsp-server to 1) minimise the amount of VSCode specific code and 2) avoid having to work with and fix bugs in typescript code ;) This commit takes us most of the way there; what is missing is the ability to create files (via a WorkspaceEditRequest), which is not yet implemented by haskell-lsp-types. I will wait with exposing the corresponding command (and removing the existing preview code) in vscode-dhall-lsp-server until this is fixed upstream.
2019-06-13 16:23:48 +02:00
Dhall.LSP.Backend.ToJSON
dhall-lsp-server: Type on hover (#1008) * Type on Hover 1/2: Backend Adds a function typeAt that, given an annotated expression and a text position finds the type of the subexpression at that position. * Type on Hover 2/2: Frontend Exposes the new type-on-hover functionality as part of the hover handler. * Simplify explainDiagnosis As suggested by @Gabriel439 * Simplify `inside` Adressing @Gabriel439's comment. * Simplify typeAt' by assuming well-typedness * Simply srcAt Use choice operator `<|>` instead of case distinction
2019-06-17 12:37:38 +02:00
Dhall.LSP.Backend.Typing
Simplify dhall-lsp-server and reorganise its modules (#992) * Clean up dhall-lsp-server's Main.hs Also adds haddock comments. * Remove TODO comment The comment talks about adding a mechanism for protocol-level logging to dhall-lsp-server. Since the VSCode LSP implementation has this feature already baked in on the client side, we don't have to implement it ourselves. * Simplify dhall-lsp-server's infrastructure So far we had a system where we set up the LSP message handlers to relay messages to a separate dispatcher thread via a shared channel. Since our language server is at the same time designed in a completely synchronous manner, this complication turns out to be unnecessary. * Remove sample code * Fix unused variable warning * Reorganise dhall-lsp-server's module hierarchy Prefixes all modules with "Dhall.LSP.". Previously: Backend.Dhall. .Diagnostics .Formatting LSP. .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server Now: Dhall.LSP. .Backend. .Diagnostics .Formatting .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server * Make dhall-lsp-server tests compile again They still fail though!
2019-06-07 09:47:07 +02:00
Dhall.LSP.Handlers
dhall-lsp-server: Towards implementing a "convert to JSON" command (#1005) At the moment the VSCode plugin contains a hacked-together prototype of a dhall-to-json (and -to-yaml) preview feature. We should ultimately move that kind of functionality to dhall-lsp-server to 1) minimise the amount of VSCode specific code and 2) avoid having to work with and fix bugs in typescript code ;) This commit takes us most of the way there; what is missing is the ability to create files (via a WorkspaceEditRequest), which is not yet implemented by haskell-lsp-types. I will wait with exposing the corresponding command (and removing the existing preview code) in vscode-dhall-lsp-server until this is fixed upstream.
2019-06-13 16:23:48 +02:00
Dhall.LSP.Handlers.Command
Simplify dhall-lsp-server and reorganise its modules (#992) * Clean up dhall-lsp-server's Main.hs Also adds haddock comments. * Remove TODO comment The comment talks about adding a mechanism for protocol-level logging to dhall-lsp-server. Since the VSCode LSP implementation has this feature already baked in on the client side, we don't have to implement it ourselves. * Simplify dhall-lsp-server's infrastructure So far we had a system where we set up the LSP message handlers to relay messages to a separate dispatcher thread via a shared channel. Since our language server is at the same time designed in a completely synchronous manner, this complication turns out to be unnecessary. * Remove sample code * Fix unused variable warning * Reorganise dhall-lsp-server's module hierarchy Prefixes all modules with "Dhall.LSP.". Previously: Backend.Dhall. .Diagnostics .Formatting LSP. .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server Now: Dhall.LSP. .Backend. .Diagnostics .Formatting .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server * Make dhall-lsp-server tests compile again They still fail though!
2019-06-07 09:47:07 +02:00
Dhall.LSP.Handlers.Diagnostics
Dhall.LSP.Handlers.DocumentFormatting
dhall-lsp-server: Towards implementing a "convert to JSON" command (#1005) At the moment the VSCode plugin contains a hacked-together prototype of a dhall-to-json (and -to-yaml) preview feature. We should ultimately move that kind of functionality to dhall-lsp-server to 1) minimise the amount of VSCode specific code and 2) avoid having to work with and fix bugs in typescript code ;) This commit takes us most of the way there; what is missing is the ability to create files (via a WorkspaceEditRequest), which is not yet implemented by haskell-lsp-types. I will wait with exposing the corresponding command (and removing the existing preview code) in vscode-dhall-lsp-server until this is fixed upstream.
2019-06-13 16:23:48 +02:00
Dhall.LSP.Handlers.Hover
Simplify dhall-lsp-server and reorganise its modules (#992) * Clean up dhall-lsp-server's Main.hs Also adds haddock comments. * Remove TODO comment The comment talks about adding a mechanism for protocol-level logging to dhall-lsp-server. Since the VSCode LSP implementation has this feature already baked in on the client side, we don't have to implement it ourselves. * Simplify dhall-lsp-server's infrastructure So far we had a system where we set up the LSP message handlers to relay messages to a separate dispatcher thread via a shared channel. Since our language server is at the same time designed in a completely synchronous manner, this complication turns out to be unnecessary. * Remove sample code * Fix unused variable warning * Reorganise dhall-lsp-server's module hierarchy Prefixes all modules with "Dhall.LSP.". Previously: Backend.Dhall. .Diagnostics .Formatting LSP. .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server Now: Dhall.LSP. .Backend. .Diagnostics .Formatting .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server * Make dhall-lsp-server tests compile again They still fail though!
2019-06-07 09:47:07 +02:00
Dhall.LSP.Server
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
other-modules:
Paths_dhall_lsp_server
Simplify dhall-lsp-server and reorganise its modules (#992) * Clean up dhall-lsp-server's Main.hs Also adds haddock comments. * Remove TODO comment The comment talks about adding a mechanism for protocol-level logging to dhall-lsp-server. Since the VSCode LSP implementation has this feature already baked in on the client side, we don't have to implement it ourselves. * Simplify dhall-lsp-server's infrastructure So far we had a system where we set up the LSP message handlers to relay messages to a separate dispatcher thread via a shared channel. Since our language server is at the same time designed in a completely synchronous manner, this complication turns out to be unnecessary. * Remove sample code * Fix unused variable warning * Reorganise dhall-lsp-server's module hierarchy Prefixes all modules with "Dhall.LSP.". Previously: Backend.Dhall. .Diagnostics .Formatting LSP. .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server Now: Dhall.LSP. .Backend. .Diagnostics .Formatting .Handlers .Handlers. .Diagnostics .DocumentFormatting .Server * Make dhall-lsp-server tests compile again They still fail though!
2019-06-07 09:47:07 +02:00
Dhall.LSP.Util
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
hs-source-dirs:
src
default-extensions: LambdaCase OverloadedStrings FlexibleInstances TypeApplications RecordWildCards ScopedTypeVariables
build-depends:
aeson
dhall-lsp-server: Towards implementing a "convert to JSON" command (#1005) At the moment the VSCode plugin contains a hacked-together prototype of a dhall-to-json (and -to-yaml) preview feature. We should ultimately move that kind of functionality to dhall-lsp-server to 1) minimise the amount of VSCode specific code and 2) avoid having to work with and fix bugs in typescript code ;) This commit takes us most of the way there; what is missing is the ability to create files (via a WorkspaceEditRequest), which is not yet implemented by haskell-lsp-types. I will wait with exposing the corresponding command (and removing the existing preview code) in vscode-dhall-lsp-server until this is fixed upstream.
2019-06-13 16:23:48 +02:00
, aeson-pretty
Fix LSP diagnostics to trailing whitespace (#974) * dhall-lsp-server: Revert from Relude to standard Prelude The code so far used Relude in place of the standard Prelude. Reverting back to the standard Prelude brings dhall-lsp-server in line with the rest of the dhall-haskell family, while also reducing the barrier to contribution. This change causes a number of additional explicit imports; creating a "Library" module to gather the common imports could perhaps solve both problems, i.e. reducing overhead while not having to resort to a custom prelude. (This is left for a future refactoring.) * dhall-lsp-server: Exclude trailing whitespace in diagnostics Dhall's current parser includes trailing whitespace in source range annotations. Until now, we simply passed these "loose" ranges on to the LSP client when generating diagnostic messages; this behaviour is fixed in the present commit. Previously (assuming funcTion is misspelled): funcTion argument ~~~~~~~~~ Now: funcTion argument ~~~~~~~~ * Refactor lines' to return NonEmpty list Thanks to Gabriel for pointing this out! Since "lines'" always returns at least a singleton list containing the empty line we can reflect this in its type; this allows us to get rid of a test for non-emptiness in "offsetToPosition".
2019-05-29 23:38:02 +02:00
, base >=4.7 && <5
dhall-lsp-server: Towards implementing a "convert to JSON" command (#1005) At the moment the VSCode plugin contains a hacked-together prototype of a dhall-to-json (and -to-yaml) preview feature. We should ultimately move that kind of functionality to dhall-lsp-server to 1) minimise the amount of VSCode specific code and 2) avoid having to work with and fix bugs in typescript code ;) This commit takes us most of the way there; what is missing is the ability to create files (via a WorkspaceEditRequest), which is not yet implemented by haskell-lsp-types. I will wait with exposing the corresponding command (and removing the existing preview code) in vscode-dhall-lsp-server until this is fixed upstream.
2019-06-13 16:23:48 +02:00
, bytestring
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
, containers
, data-default
, dhall
dhall-lsp-server: Towards implementing a "convert to JSON" command (#1005) At the moment the VSCode plugin contains a hacked-together prototype of a dhall-to-json (and -to-yaml) preview feature. We should ultimately move that kind of functionality to dhall-lsp-server to 1) minimise the amount of VSCode specific code and 2) avoid having to work with and fix bugs in typescript code ;) This commit takes us most of the way there; what is missing is the ability to create files (via a WorkspaceEditRequest), which is not yet implemented by haskell-lsp-types. I will wait with exposing the corresponding command (and removing the existing preview code) in vscode-dhall-lsp-server until this is fixed upstream.
2019-06-13 16:23:48 +02:00
, dhall-json
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
, filepath
, haskell-lsp
, hslogger
, lens
, lens-family-core
, megaparsec
, mtl
, optparse-applicative
, prettyprinter
, sorted-list
, stm
, text
, transformers
, unordered-containers
dhall-lsp-server: Rework diagnostics backend + detailed error messages on hover (#982) * Refactor Diagnostics backend This commits refactors Backend.Dhall.Diagnostics, cleaning things up and adding comments along the way. We also lose Backend.Dhall.DhallErrors. The user-facing result is a step backwards, as we revert to using Dhall's Show instances to print errors, which gives us error messages that don't fit the LSP use case very well at the moment. In the future we should change Dhall's error printing API (the Show instances) to make them more generally useful (in particular for the LSP use case), thus saving us from having to duplicate code (as was previously did, when dhall-lsp-server was not yet part of the upstream project). * Proof of concept: Provide detailed error messages This proof of concept provides detailed explanations on hovering over type errors. Currently this is done by injecting the explanation directly into the hover text, which 1. conflicts with the short error messages, which are still being displayed at the same time and 2. is not particularly readable, since the explanations are meant to be rendered at least 80 characters wide. For future work I am planning to instead only add an "explain" link to the hover window, which when clicked opens the explanation in a separate window (inspired by how the haskell ide engine presents documentation links). This will require a small amount of client-side logic. * Explain error messages via VSCode Command URIs The first proof of concept simply spit out the explanations as hover text; in order to make the feature a bit more useful, we now encode the explanation text into a VSCode command URI (that still needs to be implemented client-side), so that upon hovering over an error the user is presented with a clickable "Explain error message" link. The feature is still in the prototype stage! * Use custom URI scheme instead of command URIs Use URIs of the form "dhall-explain:?text" to present detailed explanations on hovering. Previously we used command URIs, which are specific to VSCode. Needs a correspondingly patched vscode-lsp-server to handle the "dhall-explain" URI scheme. * Fix handling of relative imports in diagnostics In refactoring the diagnostics backend I forgot to initialise the settings passed to the Dhall type-checker, which are needed to properly resolve relative imports. An easy fix for a silly mistake ;) * Remove outdated TODO comment * Make GHC stricter when building dhall-lsp-server Add -Wall and -fwarn-incomplete-uni-patterns to the GHC options when building dhall-lsp-server. This brings it in line with the rest of dhall-haskell. * Fix warnings when building dhall-lsp-server * Fix review comments Fixes Gabriel's PR comments. Note that I leave a proper fix to DhallException for the future (I want to work on something else for a bit ;)). * Use underscores to pacify warnings
2019-06-04 18:48:06 +02:00
, uri-encode
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
, yi-rope
default-language: Haskell2010
dhall-lsp-server: Rework diagnostics backend + detailed error messages on hover (#982) * Refactor Diagnostics backend This commits refactors Backend.Dhall.Diagnostics, cleaning things up and adding comments along the way. We also lose Backend.Dhall.DhallErrors. The user-facing result is a step backwards, as we revert to using Dhall's Show instances to print errors, which gives us error messages that don't fit the LSP use case very well at the moment. In the future we should change Dhall's error printing API (the Show instances) to make them more generally useful (in particular for the LSP use case), thus saving us from having to duplicate code (as was previously did, when dhall-lsp-server was not yet part of the upstream project). * Proof of concept: Provide detailed error messages This proof of concept provides detailed explanations on hovering over type errors. Currently this is done by injecting the explanation directly into the hover text, which 1. conflicts with the short error messages, which are still being displayed at the same time and 2. is not particularly readable, since the explanations are meant to be rendered at least 80 characters wide. For future work I am planning to instead only add an "explain" link to the hover window, which when clicked opens the explanation in a separate window (inspired by how the haskell ide engine presents documentation links). This will require a small amount of client-side logic. * Explain error messages via VSCode Command URIs The first proof of concept simply spit out the explanations as hover text; in order to make the feature a bit more useful, we now encode the explanation text into a VSCode command URI (that still needs to be implemented client-side), so that upon hovering over an error the user is presented with a clickable "Explain error message" link. The feature is still in the prototype stage! * Use custom URI scheme instead of command URIs Use URIs of the form "dhall-explain:?text" to present detailed explanations on hovering. Previously we used command URIs, which are specific to VSCode. Needs a correspondingly patched vscode-lsp-server to handle the "dhall-explain" URI scheme. * Fix handling of relative imports in diagnostics In refactoring the diagnostics backend I forgot to initialise the settings passed to the Dhall type-checker, which are needed to properly resolve relative imports. An easy fix for a silly mistake ;) * Remove outdated TODO comment * Make GHC stricter when building dhall-lsp-server Add -Wall and -fwarn-incomplete-uni-patterns to the GHC options when building dhall-lsp-server. This brings it in line with the rest of dhall-haskell. * Fix warnings when building dhall-lsp-server * Fix review comments Fixes Gabriel's PR comments. Note that I leave a proper fix to DhallException for the future (I want to work on something else for a bit ;)). * Use underscores to pacify warnings
2019-06-04 18:48:06 +02:00
GHC-Options: -Wall -fwarn-incomplete-uni-patterns
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
executable dhall-lsp-server
main-is: Main.hs
other-modules:
Paths_dhall_lsp_server
hs-source-dirs:
app
default-extensions: LambdaCase OverloadedStrings FlexibleInstances TypeApplications RecordWildCards ScopedTypeVariables
ghc-options: -rtsopts
build-depends:
aeson
Fix LSP diagnostics to trailing whitespace (#974) * dhall-lsp-server: Revert from Relude to standard Prelude The code so far used Relude in place of the standard Prelude. Reverting back to the standard Prelude brings dhall-lsp-server in line with the rest of the dhall-haskell family, while also reducing the barrier to contribution. This change causes a number of additional explicit imports; creating a "Library" module to gather the common imports could perhaps solve both problems, i.e. reducing overhead while not having to resort to a custom prelude. (This is left for a future refactoring.) * dhall-lsp-server: Exclude trailing whitespace in diagnostics Dhall's current parser includes trailing whitespace in source range annotations. Until now, we simply passed these "loose" ranges on to the LSP client when generating diagnostic messages; this behaviour is fixed in the present commit. Previously (assuming funcTion is misspelled): funcTion argument ~~~~~~~~~ Now: funcTion argument ~~~~~~~~ * Refactor lines' to return NonEmpty list Thanks to Gabriel for pointing this out! Since "lines'" always returns at least a singleton list containing the empty line we can reflect this in its type; this allows us to get rid of a test for non-emptiness in "offsetToPosition".
2019-05-29 23:38:02 +02:00
, base >=4.7 && <5
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
, containers
, data-default
, dhall
, dhall-lsp-server
, filepath
, haskell-lsp
, hslogger
, lens
, lens-family-core
, megaparsec
, mtl
, optparse-applicative
, prettyprinter
, sorted-list
, stm
, text
, transformers
, unordered-containers
, yi-rope
default-language: Haskell2010
dhall-lsp-server: Rework diagnostics backend + detailed error messages on hover (#982) * Refactor Diagnostics backend This commits refactors Backend.Dhall.Diagnostics, cleaning things up and adding comments along the way. We also lose Backend.Dhall.DhallErrors. The user-facing result is a step backwards, as we revert to using Dhall's Show instances to print errors, which gives us error messages that don't fit the LSP use case very well at the moment. In the future we should change Dhall's error printing API (the Show instances) to make them more generally useful (in particular for the LSP use case), thus saving us from having to duplicate code (as was previously did, when dhall-lsp-server was not yet part of the upstream project). * Proof of concept: Provide detailed error messages This proof of concept provides detailed explanations on hovering over type errors. Currently this is done by injecting the explanation directly into the hover text, which 1. conflicts with the short error messages, which are still being displayed at the same time and 2. is not particularly readable, since the explanations are meant to be rendered at least 80 characters wide. For future work I am planning to instead only add an "explain" link to the hover window, which when clicked opens the explanation in a separate window (inspired by how the haskell ide engine presents documentation links). This will require a small amount of client-side logic. * Explain error messages via VSCode Command URIs The first proof of concept simply spit out the explanations as hover text; in order to make the feature a bit more useful, we now encode the explanation text into a VSCode command URI (that still needs to be implemented client-side), so that upon hovering over an error the user is presented with a clickable "Explain error message" link. The feature is still in the prototype stage! * Use custom URI scheme instead of command URIs Use URIs of the form "dhall-explain:?text" to present detailed explanations on hovering. Previously we used command URIs, which are specific to VSCode. Needs a correspondingly patched vscode-lsp-server to handle the "dhall-explain" URI scheme. * Fix handling of relative imports in diagnostics In refactoring the diagnostics backend I forgot to initialise the settings passed to the Dhall type-checker, which are needed to properly resolve relative imports. An easy fix for a silly mistake ;) * Remove outdated TODO comment * Make GHC stricter when building dhall-lsp-server Add -Wall and -fwarn-incomplete-uni-patterns to the GHC options when building dhall-lsp-server. This brings it in line with the rest of dhall-haskell. * Fix warnings when building dhall-lsp-server * Fix review comments Fixes Gabriel's PR comments. Note that I leave a proper fix to DhallException for the future (I want to work on something else for a bit ;)). * Use underscores to pacify warnings
2019-06-04 18:48:06 +02:00
GHC-Options: -Wall -fwarn-incomplete-uni-patterns
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
test-suite dhall-lsp-server-test
type: exitcode-stdio-1.0
LSP. Fix import errors location. Minor clean-up. Add tests for backend/diagnostics. (#868)
2019-03-26 14:20:25 +01:00
main-is: Driver.hs
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
other-modules:
Paths_dhall_lsp_server
LSP. Fix import errors location. Minor clean-up. Add tests for backend/diagnostics. (#868)
2019-03-26 14:20:25 +01:00
Backend.Dhall.DiagnosticsSpec
dhall-lsp-server: Towards implementing a "convert to JSON" command (#1005) At the moment the VSCode plugin contains a hacked-together prototype of a dhall-to-json (and -to-yaml) preview feature. We should ultimately move that kind of functionality to dhall-lsp-server to 1) minimise the amount of VSCode specific code and 2) avoid having to work with and fix bugs in typescript code ;) This commit takes us most of the way there; what is missing is the ability to create files (via a WorkspaceEditRequest), which is not yet implemented by haskell-lsp-types. I will wait with exposing the corresponding command (and removing the existing preview code) in vscode-dhall-lsp-server until this is fixed upstream.
2019-06-13 16:23:48 +02:00
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
hs-source-dirs:
test
default-extensions: LambdaCase OverloadedStrings FlexibleInstances TypeApplications RecordWildCards ScopedTypeVariables
dhall-lsp-server: Rework diagnostics backend + detailed error messages on hover (#982) * Refactor Diagnostics backend This commits refactors Backend.Dhall.Diagnostics, cleaning things up and adding comments along the way. We also lose Backend.Dhall.DhallErrors. The user-facing result is a step backwards, as we revert to using Dhall's Show instances to print errors, which gives us error messages that don't fit the LSP use case very well at the moment. In the future we should change Dhall's error printing API (the Show instances) to make them more generally useful (in particular for the LSP use case), thus saving us from having to duplicate code (as was previously did, when dhall-lsp-server was not yet part of the upstream project). * Proof of concept: Provide detailed error messages This proof of concept provides detailed explanations on hovering over type errors. Currently this is done by injecting the explanation directly into the hover text, which 1. conflicts with the short error messages, which are still being displayed at the same time and 2. is not particularly readable, since the explanations are meant to be rendered at least 80 characters wide. For future work I am planning to instead only add an "explain" link to the hover window, which when clicked opens the explanation in a separate window (inspired by how the haskell ide engine presents documentation links). This will require a small amount of client-side logic. * Explain error messages via VSCode Command URIs The first proof of concept simply spit out the explanations as hover text; in order to make the feature a bit more useful, we now encode the explanation text into a VSCode command URI (that still needs to be implemented client-side), so that upon hovering over an error the user is presented with a clickable "Explain error message" link. The feature is still in the prototype stage! * Use custom URI scheme instead of command URIs Use URIs of the form "dhall-explain:?text" to present detailed explanations on hovering. Previously we used command URIs, which are specific to VSCode. Needs a correspondingly patched vscode-lsp-server to handle the "dhall-explain" URI scheme. * Fix handling of relative imports in diagnostics In refactoring the diagnostics backend I forgot to initialise the settings passed to the Dhall type-checker, which are needed to properly resolve relative imports. An easy fix for a silly mistake ;) * Remove outdated TODO comment * Make GHC stricter when building dhall-lsp-server Add -Wall and -fwarn-incomplete-uni-patterns to the GHC options when building dhall-lsp-server. This brings it in line with the rest of dhall-haskell. * Fix warnings when building dhall-lsp-server * Fix review comments Fixes Gabriel's PR comments. Note that I leave a proper fix to DhallException for the future (I want to work on something else for a bit ;)). * Use underscores to pacify warnings
2019-06-04 18:48:06 +02:00
ghc-options: -threaded -rtsopts -with-rtsopts=-N -Wall
dhall-lsp-server: add tasty-discover to build-tool-depends. (#963) The test-suite uses the executable at build-time. New-style cabal-install requires it to be mentioned in build-tool-depends.
2019-05-23 04:19:13 +02:00
build-tool-depends:
tasty-discover:tasty-discover
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
build-depends:
aeson
Fix LSP diagnostics to trailing whitespace (#974) * dhall-lsp-server: Revert from Relude to standard Prelude The code so far used Relude in place of the standard Prelude. Reverting back to the standard Prelude brings dhall-lsp-server in line with the rest of the dhall-haskell family, while also reducing the barrier to contribution. This change causes a number of additional explicit imports; creating a "Library" module to gather the common imports could perhaps solve both problems, i.e. reducing overhead while not having to resort to a custom prelude. (This is left for a future refactoring.) * dhall-lsp-server: Exclude trailing whitespace in diagnostics Dhall's current parser includes trailing whitespace in source range annotations. Until now, we simply passed these "loose" ranges on to the LSP client when generating diagnostic messages; this behaviour is fixed in the present commit. Previously (assuming funcTion is misspelled): funcTion argument ~~~~~~~~~ Now: funcTion argument ~~~~~~~~ * Refactor lines' to return NonEmpty list Thanks to Gabriel for pointing this out! Since "lines'" always returns at least a singleton list containing the empty line we can reflect this in its type; this allows us to get rid of a test for non-emptiness in "offsetToPosition".
2019-05-29 23:38:02 +02:00
, base >=4.7 && <5
Add dhall-lsp-server (#843)
2019-03-07 06:41:38 +01:00
, containers
, data-default
, dhall
, dhall-lsp-server
, filepath
, haskell-lsp
, hslogger
, lens
, lens-family-core
, megaparsec
, mtl
, optparse-applicative
, prettyprinter
, sorted-list
, stm
, tasty
, tasty-discover
, tasty-hspec
, tasty-quickcheck
, text
, transformers
, unordered-containers
, yi-rope
default-language: Haskell2010
Reference in New Issue Copy Permalink