You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in #117go-lsp currently provides us structs which represent requests/responses, but regardless of what library we use, it will inevitably be behind at some point.
Even if the library stays on top of spec changes, there's the long tail of:
a) language servers actually updating in time, and
b) end-users of these LS updating in time
Generally the problem is that clients will move at a different pace to servers and neither side has any way of controlling that pace, because the protocol doesn't do any version negotiation.
Attempted Solutions
The upstream jrpc2 library implements strict JSON unmarshaling, which motivated sourcegraph/go-lsp#8 to implement "loose" unmarshaling, which came with a flaw related to unmarshalers in embedded structs.
Proposal
Turn off the strict mode in jrpc2. This will require reopening creachadair/jrpc2#5 in some form or shape.
The text was updated successfully, but these errors were encountered:
This was resolved as part of creachadair/jrpc2#32 - unknown fields are now ignored by default, which is also the default behaviour of the native Go JSON decoder, we can upgrade to the latest version.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the context necessary to investigate further.
ghost
locked as resolved and limited conversation to collaborators
Dec 18, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Current Version
Context
As mentioned in #117
go-lsp
currently provides us structs which represent requests/responses, but regardless of what library we use, it will inevitably be behind at some point.Even if the library stays on top of spec changes, there's the long tail of:
a) language servers actually updating in time, and
b) end-users of these LS updating in time
Generally the problem is that clients will move at a different pace to servers and neither side has any way of controlling that pace, because the protocol doesn't do any version negotiation.
Attempted Solutions
The upstream jrpc2 library implements strict JSON unmarshaling, which motivated sourcegraph/go-lsp#8 to implement "loose" unmarshaling, which came with a flaw related to unmarshalers in embedded structs.
Proposal
Turn off the strict mode in jrpc2. This will require reopening creachadair/jrpc2#5 in some form or shape.
The text was updated successfully, but these errors were encountered: