-
Notifications
You must be signed in to change notification settings - Fork 131
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
Replace sourcegraph/go-lsp with gopls' internal/lsp/protocol #311
Conversation
bb0fbe3
to
5f50544
Compare
5f50544
to
b49ae2a
Compare
// when len(cc.Hover.ContentFormat) == 0, but that's not possible | ||
// without changing lsp.Hover.Content field type to interface{} | ||
// | ||
// We choose to follow gopls' approach (i.e. cut off old clients). |
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.
This was discussed briefly in microsoft/language-server-protocol#1144 (comment)
|
||
func decodeRequestID(v interface{}) (string, error) { | ||
if val, ok := v.(string); ok { | ||
return val, nil |
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.
sourcegraph/go-lsp
actually quoted string IDs
but I'm considering that a bug which we never encountered because of how rarely strings are used by language clients (most use numbers, which in case of go-lsp
were interpreted as uint64
and in gopls' as float64
). Either way, if the client expects the server to quote the ID I would consider that a bug on the client side too, because from what I can tell the spec doesn't mention anything about quoting IDs:
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#requestMessage
|
||
url := fmt.Sprintf(urlFmt, goplsRef) | ||
|
||
resp, err := http.Get(url) |
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.
This is a simpler way of extracting it compared to govim's approach, which we can apply just because we're only interested in the protocol structs and nothing else and thankfully everything is contained within that one file and that file does not have any non-stdlib imports.
It may need to be revisited if/when we consider extracting anything else.
b49ae2a
to
ece38e2
Compare
CI tests will get triggered once #313 is merged and this PR is rebased. |
It would be best to import this like a normal package, but gopls team doesn't feel confident about the stability of their generator and so this remains under internal for now. That said this is still currently the most accurate and up to date structs we can get for Go today with little effort.
ece38e2
to
ebe0729
Compare
ebe0729
to
bce3e94
Compare
bce3e94
to
d93a6fa
Compare
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. |
Closes #117
The most visible difference between the two libraries is probably the change from
int
tofloat
which may look awkward especially in the context of line or column numbers, but this is mostly a side effect of the code being generated from TypeScript, wherenumber
may or may not have a fractional part. TypeScript does not differentiate so strictly betweenfloat
andint
unlike Go.