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

fixes bug with textDocument/definition on LanguageClient-neovim #13

Closed
wants to merge 6 commits into from

Conversation

martskins
Copy link
Contributor

It seems like LanguageClient-neovim sends extra data on the textDocument/definition request, which casues the server to fail the validation. I added those fields as optionals to the message schema and it seems to solve the issue.

I also found that I was getting constant errors about LanguageServer-neovim failing to deserialize the position params when it received a -1, as it expects an u64. Passing 0 instead seems to stop the constant errors.

@PMunch
Copy link
Owner

PMunch commented Nov 10, 2018

Hmm yeah, I noticed Sublime also sent some extra data. Seems like most implementations aren't as strict as ours in checking their data.. But this will quickly become unmaintainable for us if we have to add a special case field for every editor out there, so I think I'll fix this by introducing a relaxed check parameter to isValid that will allow it to have more fields than those required. This would allow others to throw in as many superfluous fields as they'd like, as long as they have the fields that we actually need (and these will still be checked).

The position parameter thing is a bit more tricky. It seems that the issue here is that Nim can return things with negative position if it's a general error and not related to some specific part of the document. I think it would be better to change this check to also disallow these numbers, and find some other way of returning them that doesn't require us to place them within a document.

@PMunch
Copy link
Owner

PMunch commented Nov 10, 2018

I left a comment over in the main LSP repository. Apparently this is not a new issue, but something that hasn't been resolved yet: microsoft/language-server-protocol#256 (comment)

response.add create(Diagnostic,
create(Range,
create(Position, diagnostic.line-1, diagnostic.column),
create(Position, diagnostic.line-1, max(diagnostic.column, endcolumn))
create(Position, diagnosticLine, diagnosticColumn),
Copy link
Owner

Choose a reason for hiding this comment

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

This should always be diagnostic.column, and not endColumn. This logic was stolen from the VSCode plugin which tries to find the thing that was wrong and underline it. So the range here is supposed to go from where Nim finds the issue, and to the end of the thing that is in error.

@@ -387,11 +387,13 @@ while true:
# Try to guess the size of the identifier
let
message = diagnostic.nimDocstring
endcolumn = diagnostic.column + message.rfind('\'') - message.find('\'') - 1
endcolumn = max(diagnostic.column + message.rfind('\'') - message.find('\'') - 1, 0)
Copy link
Owner

Choose a reason for hiding this comment

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

This doesn't really do much as it got max'ed with diagnostic.column later anyways. I think the problem here is that things with line or column <0 aren't visible in the document and therefore should be returned in some other way.

rawLine = name["position"]["line"].getInt
rawChar = name["position"]["character"].getInt
rawLine = max(name["position"]["line"].getInt, 0)
rawChar = max(name["position"]["character"].getInt, 0)
Copy link
Owner

Choose a reason for hiding this comment

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

This change means that rawLine and rawChar aren't really raw any longer so it should be renamed to something else.

@PMunch
Copy link
Owner

PMunch commented Nov 10, 2018

I also noticed that chk replies without a file when the position is not within the document. Maybe this is the criteria we should use to filter out these entries.

@PMunch
Copy link
Owner

PMunch commented Nov 10, 2018

Just added an allowExtra field to jsonschema that allows the JSON data to have more fields than those checked, this should prevent us from having to add a whole lot of new fields (but still only allow the compile-time checking of the fields that do exist).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants