-
Notifications
You must be signed in to change notification settings - Fork 214
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
[LSP] Added Symbol Renaming to the language server #1948
Conversation
3a47eda
to
f523773
Compare
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## master #1948 +/- ##
==========================================
- Coverage 92.84% 92.80% -0.04%
==========================================
Files 355 355
Lines 26113 26206 +93
==========================================
+ Hits 24245 24321 +76
- Misses 1868 1885 +17
☔ View full report in Codecov by Sentry. |
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.
Exciting, this will be a very cool feature!
A few first comments.
int character; | ||
}; | ||
|
||
std::string RenameRequest(RenameRequestParams params) { |
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.
Instead of manually converting things to json, can you use the generated verible::lsp:: structs to fill and then just use the to_json() to convert it ?
Also we wouldn't need this RenameRequestParams
struct here, we can directly use verible::lsp::PrepareRenameParams
and verible::lsp::RenameParams
.
The PrepareRenameRequest() and RenameRequest() functions then can take a verible::lsp::TextDocumentPositionParams
.
I hope that longer term, we can mostly use these structs here and have our EXPECT_EQ() and stuff also look into these instead of manually poking in json arrays. This will be a cleanup PR at some point, but if we can already have new code with that in mind would be good.
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 have changed the methods such that they place the (Prepare)RenameParams
into a prepared snippet of JSON. Using to_json()
didn't make sense here, as it dumps the contents of the struct only, however the request itself also requres an ID, method and other boilerplate. Methods built into the tests already use this approach (such as ReferencesRequest()
and I have found no logical way to construct a full request in any other manner.
EXPECT_EQ(response["result"]["changes"][params.file].size(), 3) | ||
<< "Invalid result size for id: "; | ||
} | ||
|
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.
Additional possible tests: put the cursor over the definition of a symbol in one test and over one reference of a symbol. In both cases, the definition and all references should be updated.
Also other corner cases
- symbol defined in a package ? Making sure that the same symbolname ('foo') defined in two different packages is not cross-renaming the other package symbol
PackageA::foo
andPackageB::foo
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.
The first test: this is known to be broken and expected to be fixed by #1678 (as well as the duplication of positions with module names); I will add the test and remove duplicate finding once that PR gets merged, if that is okay.
As for the second one: added it and it works as expected.
feb3e8e
to
b20a9c3
Compare
0c5ebc9
to
188c90e
Compare
Added the support to respond to prepareRename requests for the LSP, such that it provides locations for the naming changes that will be made once a proper rename will be sent Signed-off-by: Jan Bylicki <[email protected]>
Added protocol implementation for rename capability. No actual action will be taken but in testing there are no errors editor-side by now. Signed-off-by: Jan Bylicki <[email protected]>
Added an option to do a textDocument/rename LSP operation that will locate and send ranges for the editor to change. Signed-off-by: Jan Bylicki <[email protected]>
Signed-off-by: Jan Bylicki <[email protected]>
Signed-off-by: Jan Bylicki <[email protected]>
…name spec Signed-off-by: Jan Bylicki <[email protected]>
… issues Signed-off-by: Jan Bylicki <[email protected]>
Signed-off-by: Jan Bylicki <[email protected]>
c795f14
to
dbdcbba
Compare
f04e748
to
66fe077
Compare
8936233
to
5161a26
Compare
I have added a fix that checks for duplicates in replace positions. That fix should be redundant once a PR fixing go-to-definition works, as stated in a comment in this commit Signed-off-by: Jan Bylicki <[email protected]>
Signed-off-by: Jan Bylicki <[email protected]>
Added a rename test that checks whether renaming across files works Signed-off-by: Jan Bylicki <[email protected]>
Signed-off-by: Jan Bylicki <[email protected]>
b74fcdf
to
861087e
Compare
Signed-off-by: Jan Bylicki <[email protected]>
861087e
to
2a1ec3e
Compare
Signed-off-by: Jan Bylicki <[email protected]>
Signed-off-by: Jan Bylicki <[email protected]>
cb9e063
to
8e909d9
Compare
Looks pretty good. If you rebase, the symbol table handler has a little failure, that would probably need to be addressed. The above coverage tool claims that only 86% of the changes have coverage, are there missed test opportunities ? |
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.
Ready to submit after rebase.
Rebased, then merged as #2081 |
This PR implements functionality for
textDocument/prepareRename
andtextDocument/rename
capabilities.