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

feat: Path patching API #709

Merged
merged 1 commit into from
Dec 17, 2024
Merged

Conversation

angelozerr
Copy link
Contributor

Path patching API

Fixes #702

@angelozerr angelozerr changed the title Path patching API feat: Path patching API Dec 17, 2024
@angelozerr angelozerr force-pushed the file_uri_api branch 7 times, most recently from ba3bb52 to 13e625d Compare December 17, 2024 17:13
@angelozerr angelozerr marked this pull request as ready for review December 17, 2024 17:15
@angelozerr
Copy link
Contributor Author

@SCWells72 is it possible that you test my PR just to check that I have not broken something.

I would like to merge it ASAP to use it when we will develop other features and discover some potential problem.

Thanks!

@InSyncWithFoo you can test the PR if you wish by installing build zip.

Copy link
Contributor

@SCWells72 SCWells72 left a comment

Choose a reason for hiding this comment

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

Given the breadth of this change, it's difficult for me to ascertain the risk of it. Conceptually it makes sense, but I think you're largely going to have to rely on the unit tests (and perhaps some additional manual testing?) to make sure it's solid.

I did add a comment on at least one potential NPE (via a mismatched nullability annotation/usage) in this review, and I'd definitely recommend that you make a pass and confirm that all parameters that could be null are being treated as such...and ideally add nullability annotations that make those contracts clear.

@@ -73,9 +73,11 @@ protected CompletableFuture<List<DocumentSymbolData>> doLoad(DocumentSymbolParam
}

private static CompletableFuture<List<DocumentSymbolData>> getDocumentSymbolsFor(@NotNull DocumentSymbolParams params,
@NotNull PsiFile file,
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason that this signature changed to reverse the order of the second and third parameters? Perhaps this order just makes more sense, but wanted to confirm this wasn't just an accident with no motivation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did that to align this rule with other LSP*Support (see LSPCompletionSupport).

@angelozerr angelozerr force-pushed the file_uri_api branch 2 times, most recently from 7fbab55 to 3f6c56a Compare December 17, 2024 17:50
Fixes redhat-developer#702

Signed-off-by: azerr <azerr@redhat.com>
@angelozerr angelozerr merged commit 1783e36 into redhat-developer:main Dec 17, 2024
6 checks passed
@angelozerr
Copy link
Contributor Author

Thanks @SCWells72 for your review!

@angelozerr
Copy link
Contributor Author

Conceptually it makes sense, but I think you're largely going to have to rely on the unit tests (and perhaps some additional manual testing?) to make sure it's solid.

All unit test that we have for completion, etc uses the default behavior of the new API.

It would be nice to write tests with customization of the API https://github.com/redhat-developer/lsp4ij/blob/main/docs/LSPApi.md but it is very hard for me to find time to do that

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.

Path patching API
2 participants