-
Notifications
You must be signed in to change notification settings - Fork 111
Overhaul part 2/2 (Refactored Language Client, Pipelines and unit tests!) #248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… handler that uses the new pipelines for lower allocations of incomming data. Added validation tests for handler methods to ensure that all required methods exist when new handlers are added
1d5d6c1
to
cdfbbb9
Compare
Codecov Report
@@ Coverage Diff @@
## master #248 +/- ##
===========================================
+ Coverage 33.37% 62.12% +28.75%
===========================================
Files 391 383 -8
Lines 11626 11483 -143
Branches 1459 1361 -98
===========================================
+ Hits 3880 7134 +3254
+ Misses 7420 3782 -3638
- Partials 326 567 +241
Continue to review full report at Codecov.
|
…in LspClientReciever which was causing the powershell integration tests to not work correctly.
…pture unhandled exceptions during input processing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Go for it - after this, it looks like none of the original client code is left in there but at least that's one less thing for me to worry about 🙂
…pogation of cancelled results back to the caller. Also fixed an issue where request cancellation was not working. Also request cancellation would not throw custom exceptions for anyone that was task like.
…e that the JToken is not sent through the serailzier (this ensure that the casing stays correct)
…/parallel) Fixed a bug where things would lock due to response tasks being set in the same thread.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we've battle tested this code pretty well :D
So yeah... this is huge, sorry for that.
This includes the pipeline changes (and revealed a few problems with the
InputHandler
)This rewrites the
LanguageClient
to be theLanguageServer
just in reverse. Same design but mirrored methods. (ie. The server willPublishDiagostics
and the client will have anIPublishDiagnosticsHandler
to recieve them).As a core part of this change the goal is to ensure consistency between handlers. This has introduced a few things.
JsonRpc
MethodAttribute
has a new (optional) enum added to it for theDirection
this handler, which is just used a hint for a JsonRpcServer. Direction is required for both LSP and DAP protocols however, if it's missing there is a unit test which will fail.LSP/DAP
LSP
IPartialResultRequest
orIPartialResultsRequest
have an overload for dealing with partial resultsIProgressManager
IProgressManager
( https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#partialResults )MonitorUntil
TaskLike
object that is both anIObservable<T>
and{ GetAwaiter(): TaskAwaiter<TResponse> }
IServerWorkDoneManager
andIClientWorkDoneManager
( https://microsoft.github.io/language-server-protocol/specifications/specification-current/#workDoneProgress )IClientProxy
for sending requests, which will enrich the request with a work done token.IServerWorkDoneManager
that is safe to call onIWorkDoneProgressParams
even if workdone is not set, it will just be an Observer that goes no whereLSP/DAP Unit Testing
JsonRpcServer
Settle
to ensure state is consistent on both sidesITestOutputHandler
)With the new client we now have the ability to test the library in both directions to help improve code coverage as well as help with developing tests for corner cases (such as servers that don't support dynamic registration for example).