* Use our normal auto-incrementing ids instead of UUIDs
The spec just says they have to be unique IDs, not UUIDs, and we already
have a tool for generating such things.
* Remove random too
* Rewrite progress handling to allow for debouncing messages
This had to be redone in order to allow us to "wake up" and notice that
there are pending messages. I also wrote it so there can be a stateful
interface (the `ProgressTracker`) which I think might make it easier to
use in that weird case in `ghcide`. I haven't exposed that yet, though.
* Remove stateful interface
* Delay sending the create request also
* Changelog
* Move progress code to its own module
* Reject messages that come in after 'shutdown'
This is mandated by the spec so we can do it. We also expose the
shutdown barrier, which I think can be convenient. For more
sophisticated usecases people should just install a proper shutdown
handler.
I tried to write some tests for this, but I gave up because it requires
some singificant surgery on `lsp-test`, which stops recording messages
when it receives `shutdown` :(
* Fix formatting
* Update the metamodel
There are various changes:
- Quite a lot of new "proposed" stuff. I adjusted the codegen to filter
this stuff out, which is what we want I think. I had to make some PRs
upstream, I hacked up our metamodel copy to mirror what I think will
come out of that eventually.
- They created named structs for a lot of the previously anonymous ones.
This is generally pretty good, using `row-types` for that was always a
bit awkward. However, I haven't been able to get them to commit to
actually getting rid of anonymous structs entirely, so we have to keep
the support :(
- This change does generate most of the churn, though
- Some random renamings 🤷
* Try to fix on 9.8
* Register for workspace/didChangeConfiguration always
The new direction of the spec seems to be that you should always do
this. In any case, it doesn't hurt.
`lsp-test` has some changes to adapt to the increased registration
message spam, and also changes to be a more picky client, refusing to
send notifications unless you _do_ register. This is good, since it
forces us to handle the most annoying version of client behaviour.
* Add bound on extra
* fix
* Accept null in place of a missing value
We sometimes see reports where HLS is not working because the client
sends us slightly wrong JSON. We should follow the principle of
robustness and try to accept this where we can - following the spec
precisely is hard!
The specific case we hadle here is accepting null to mean "missing"
when null is not a valid value for the type. Currently we will treat
it as a _present_ value and then fail to interpret null as a value of
the type.
* Mark lsp-types generated code as generated for github
* typo
* Fix a few more
* Refactor tests a little
* Changelog
* Improve comment
* Various fixes to progress handling
1. Server-initiated progress should wait for the client to acknowledge
This is an old bug. Per the spec, we're not allowed to send any reports
using the token if the client doesn't respond with a non-error response
to our creation of the token.
This is a bit subtle, because it means we may need to delay the sending
of the "begin" notification until we have received the token from the
client.
2. No easy way to use client-initiated progress
This is simpler and faster than server-initiated progress since you
don't need the extra message round-trip. You just need to pull out
the progress token (if there is one) from the request and use that.
I did two things to make this better:
- The progress functions now take the client token if there is one.
If there isn't one they still fall back to server-initiated progress.
- The server capabilities can now advertise that client-initiated
progress is supported.
* Make the default for client-initiated progress to be off
* Don't lose progress updates if it takes a while to start
* Refactor tests
* Add test for cancellation
* Fix minor bug in lsp-test config handling
* More tests
* Try this
* Fix formatting
* Add comment and purge traces
* More cabal file tidying
Remove most constraints from non-library components. I'm unsure if this
is quite right: possibly we should have bounds for any public component,
but this is significantly more work to maintain (witness the odd bound
on `sorted-list` from a test suite). I think this strikes a reasonable
balance for now.
* Delete repeated base bounds
* Drop generic-lens workaround
* Allow filepath-1.5
* Simplify nix setup
This doesn't try to build the dependencies, just provides GHC/cabal/HLS.
* Add cabal-fmt and fourmolu
* Updated fourmolu
* Use the default GHC
HLS used to need to build with aeson 1 for old versions of GHC, but
that's no longer the case so we can finally stop maintaining
compatibility with both.
