-
Notifications
You must be signed in to change notification settings - Fork 661
Generate LSP response types, redo nullable, delete aliases, statically type LSP handlers #1441
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
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.
Pull Request Overview
This PR implements foundational changes to the LSP protocol type generation system as part of issue #1439. The changes refactor nullable type handling, remove type aliases, and generate request response types.
- Replaced custom
Nullable[T]
with generated union types containing null variants - Removed type alias generation and replaced with direct union type resolution
- Added request response type generation for LSP methods
- Updated all LSP protocol consumers to use the new generated types
Reviewed Changes
Copilot reviewed 13 out of 14 changed files in this pull request and generated 3 comments.
Show a summary per file
File | Description |
---|---|
internal/lsp/lsproto/_generate/generate.mts | Core type generation logic overhaul - new nullable handling, union type flattening, response type generation |
internal/lsp/lsproto/lsp.go | Removed custom Nullable type, added assertAtMostOne utility function |
internal/ls/signaturehelp.go | Updated to use UintegerOrNull instead of Nullable[uint32] |
internal/ls/signaturehelp_test.go | Updated test expectations to use new union type syntax |
internal/ls/hover.go | Updated to use longer generated union type name |
internal/ls/hover_test.go | Updated test expectations for new union type name |
internal/ls/diagnostics.go | Refactored to use generated union types and renamed method |
internal/ls/definition.go | Updated return types to use generated union types |
internal/ls/definition_test.go | Updated test types to match new union types |
internal/lsp/server.go | Updated method call to renamed diagnostics function |
internal/project/service.go | Updated parameter type to use generated union type |
internal/project/service_test.go | Updated test data to use new union type names |
internal/fourslash/fourslash.go | Updated to use new union type for content changes |
Okay, well I went a little overboard. Now, the request/notification handlers are fully statically typed, something I've wanted to do for a while. I also eliminated |
case *lsproto.InitializedParams: | ||
return s.handleInitialized(ctx, req) | ||
case *lsproto.DidOpenTextDocumentParams: |
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.
Changing how this works is actually a prereq for handling requests with the same params but different methods.
if resMsg == nil { | ||
t.Fatalf(prefix+"Nil response received for completion request", f.lastKnownMarkerName) | ||
} | ||
result := resMsg.AsResponse().Result | ||
switch result := result.(type) { | ||
case *lsproto.CompletionList: | ||
f.verifyCompletionsResult(t, f.currentCaretPosition, result, expected, prefix) | ||
default: | ||
t.Fatalf(prefix+"Unexpected response type for completion request: %v", result) | ||
if !resultOk { | ||
t.Fatalf(prefix+"Unexpected response type for completion request: %T", resMsg.AsResponse().Result) | ||
} |
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.
It'd be ideal if sendRequest
(or a wrapper function) automatically errored based on resMsg
and resultOk
and used the passed Method
for the errors.
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 wanted to do this, but it means I have to also pass in prefix
which felt strange...
internal/fourslash/fourslash.go
Outdated
@@ -267,20 +267,25 @@ func getCapabilitiesWithDefaults(capabilities *lsproto.ClientCapabilities) *lspr | |||
return &capabilitiesWithDefaults | |||
} | |||
|
|||
func (f *FourslashTest) sendRequest(t *testing.T, method lsproto.Method, params any) *lsproto.Message { | |||
func sendRequest[Params, Resp any](t *testing.T, f *FourslashTest, mapping lsproto.RequestInfo[Params, Resp], params Params) (*lsproto.Message, Resp, bool) { |
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.
My nit is that I'd prefer fourslash still come first, but it's fine.
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.
If I do that, then lint rules that say "t
comes first" will get mad.
|
||
writeLine(`// Type mapping info for \`${request.method}\``); | ||
if (responseTypeName) { | ||
writeLine(`var ${methodName}Info = RequestInfo[${paramGoType}, ${responseTypeName}]{Method: Method${methodName}}`); |
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.
If you don't like Info
, we can call them Mapping
s, Pairing
s, ReqRes
, or maybe some combo of those.
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 had it as "Mapping" before. ReqRes not so much because it has to also work for notifications.
|
||
// Inspired by https://www.youtube.com/watch?v=dab3I-HcTVk | ||
|
||
type RequestInfo[Params, Resp any] struct { |
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.
Given the parameter in fourslash is called mapping
, maybe it makes sense to at least call this a ParameterResponseMapping
or something
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.
That's a mistake; I meant to rename that one too.
…y type LSP handlers (#1441)
This allows us to work on #1439.