Skip to content
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

Rewrite msg dispatch #701

Merged
merged 14 commits into from
May 25, 2020
Merged

Rewrite msg dispatch #701

merged 14 commits into from
May 25, 2020

Conversation

davidanthoff
Copy link
Member

@davidanthoff davidanthoff commented May 17, 2020

This is a rewrite how messages are dispatched to handler functions. I mostly modeled this after the vscode-jsonprc package.

One main goal was to move all of the JSON aspects out of the julia functions that actually handle a request or notification. I think that will make it much easier to write tests for those functions.

@ZacLN not ready for a detailed review, but if you want to have a quick look and give feedback on the general direction, that might be a good moment.

Requires julia-vscode/JSONRPC.jl#4.

TODO

  • Fix tests
  • Remove endpoint from lint! function EDIT we can do this later.
  • Update version bound on JSONRPC

@ZacLN
Copy link
Contributor

ZacLN commented May 17, 2020

I've had a quick look - this is pretty much how I'd pictured it and seems much more sane. My only query for now is why conn is passed to the handler functions, isn't it held in the server?

@davidanthoff
Copy link
Member Author

My only query for now is why conn is passed to the handler functions, isn't it held in the server?

My hope is that I can more easily add a mock testing framework that way, so that wen can write unit tests for each message handler without ever needing to deal with real communication in those tests. If that turns out to not work we can still change things back so that these functions use the instance that is stored in the server.

@davidanthoff
Copy link
Member Author

@ZacLN I'm stuck with something around the construction of instances from JSON in this branch.

In particular, if you run tests, things don't work because there is some deserialize problem where it tries to convert a nothing to a String. I think it is somehow related to changing init_request in test_communication.jl to use the strongly typed stuff. I banged my head against this for almost an hour now and I just don't understand where the error is coming from... Could you maybe have a brief look? Just checkout this branch and run the tests, the first error should be the relevant problem. Thanks!

@ZacLN
Copy link
Contributor

ZacLN commented May 20, 2020

Yep I'll take a look. The json converter code is pretty delicate...

@ZacLN
Copy link
Contributor

ZacLN commented May 20, 2020

Ah, OK. You're trying to convert structs to JSON that we (previously) only expected to be found in incoming requests or notifications. These aren't marked as subtypes of Outbound and so this doesn't look to remove fields with missing values when converting to JSON. It should be safe to simply add the marker as in https://github.com/julia-vscode/LanguageServer.jl/blob/master/src/protocol/protocol.jl#L3

@davidanthoff
Copy link
Member Author

Ah, yes, that is it! Thanks :)

@davidanthoff davidanthoff marked this pull request as ready for review May 21, 2020 21:28
@davidanthoff davidanthoff requested a review from ZacLN May 21, 2020 21:29
Copy link
Contributor

@ZacLN ZacLN left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a biggie but looks to be good. I've left a couple comments above

src/languageserverinstance.jl Outdated Show resolved Hide resolved
@@ -239,20 +259,45 @@ function Base.run(server::LanguageServerInstance)
Base.display_error(stderr, err, bt)
end
end

msg_dispatcher = JSONRPC.MsgDispatcher()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the following maybe sit in msgdefs.jl?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so, the idea is that this is specific to this particular server who handles things, whereas the msgdefs.jl is really the file that defines the protocol.

request = parse(JSONRPC.Request, msg)

res = process(request, server)
msg = message.msg
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not introduced by this PR but I feel like message.msg indicates that one of these is incorrectly named

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but maybe better solved in a follow up PR.

src/requests/actions.jl Outdated Show resolved Hide resolved
@@ -145,12 +143,12 @@ function expand_inline_func(x, id, server)
end
newtext = string(newtext, "\nend\n")
tde = TextDocumentEdit(VersionedTextDocumentIdentifier(file._uri, file._version), TextEdit[TextEdit(Range(file, offset .+ (0:func.fullspan)), newtext)])
JSONRPCEndpoints.send_request(server.jr_endpoint, "workspace/applyEdit", ApplyWorkspaceEditParams(missing, WorkspaceEdit(nothing, TextDocumentEdit[tde])))
JSONRPC.send(conn, workspace_applyEdit_request_type, ApplyWorkspaceEditParams(missing, WorkspaceEdit(nothing, TextDocumentEdit[tde])))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated but I think the first arg to WorkspaceEdit should be missing rather than nothing. Same thing a few lines above

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Best solved in a new PR, I'd say?

src/requests/features.jl Outdated Show resolved Hide resolved
@davidanthoff
Copy link
Member Author

Thanks! I either fixed or commented on the individual points. Some of these I agree with, but it probably would be easier to do those in follow up PRs.

@davidanthoff davidanthoff merged commit 07026f4 into master May 25, 2020
@davidanthoff davidanthoff deleted the rewrite_msg_dispatch branch May 25, 2020 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants