* 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
Part of https://github.com/dhall-lang/dhall-lang/issues/563
This flag freezes imports in the same way as the Prelude by providing a
fallback unprotected import without an integrity check. The primary use
case for this is caching imports with a graceful fallback, which is why
the flag is named `--cache`
* 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".
In yaml-0.11, Text.Libyaml was split into the libyaml package. Hence,
as dhall-json imports that module, a libyaml dependency is needed when
yaml >= 0.11. This necessitates an automatic flag.
As Dhall's bounds don't allow base 4.13, this doesn't actually affect
anyone running in a supported configuration (i.e., without
--allow-newer). Further note that base 4.13 (i.e., GHC 8.8) isn't
tested in CI at present.
This could well be the last GHC 8.8-related change needed to
code (bounds will definitely need to be adjusted). In this case, a
Dhall release with relaxed bounds will suffice to finish off GHC 8.8
support.
However, it's also possible that dependencies might bundle together
breaking changes with 8.8 support, in which case adaptations will
still need to be made.
Fixes https://github.com/dhall-lang/dhall-haskell/issues/882
This allows users to supply the Dhall expression by path instead of via
standard input. This also ensures that transitive imports are resolved
appropriately relative to the file's path.
In other words, instead of this:
```
$ dhall <<< './foo/bar.dhall'
```
Users can now do:
```
$ dhall --file foo/bar.dhall
```
Before, `dhall-to-json`/`dhall-to-yaml` would use approximate
representations for special `Double` values. Specifically, `NaN`
would encode as `null` and `±Infinity` would encode as the minimum
and maximum `Double` values.
After this change, YAML will now use `nan`/`inf`/`-inf` to encode
these values (since special `Double` values are natively supported
by YAML) and the JSON encoding will reject them by default. The
user can restore the old behavior for the JSON encoding by enabling
the `--approximate-special-doubles` flag.
Allow to generare quoted scalars if needed via providing a custom encode
options to Data.Yaml.encodeWith. So far two corner cases from yaml
itself (an empty scalar, and special strings) are omitted in the
implementation.
It had bitrotted and wasn't presently building; evidently no-one was
missing it. LTS 6 is actively checked by CI, so while this loses some
coverage of dependency versions in the middle of the range, it doesn't
shrink the overall range of dependencies tested.
Closes#921.
