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

Merge definitions from all plugins for Document(Type)Definition message #3846

Merged
merged 13 commits into from
Nov 17, 2023

Conversation

JiriLojda
Copy link
Contributor

This PR fixes issue #3634 by merging the definition responses from all plugins into one definition response. It (only when necessary) transforms Location to LocationLink as suggested by @michaelpj in the issue.
I didn't refactor the type the plugins return as suggested by @joyfulmantis, because I think it will be better to address it in a separate PR and have a straightforward fix merged before that.

Copy link
Collaborator

@fendor fendor left a comment

Choose a reason for hiding this comment

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

LGTM, thank you for the addition!

One nitpick and a little bit more documentation, looks good to me as is otherwise :)

Comment on lines +699 to +714
mergeDefinitions :: Definitions -> Definitions -> Definitions
mergeDefinitions definitions1 definitions2 = case (definitions1, definitions2) of
Copy link
Collaborator

Choose a reason for hiding this comment

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

Some haddock explaining what this does, especially what the merging rules are would be great!

defToLinks (Definition (InL location)) = [DefinitionLink $ locationToLocationLink location]
defToLinks (Definition (InR locations)) = map (DefinitionLink . locationToLocationLink) locations

locationToLocationLink :: Location -> LocationLink
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nitpick

How about:

Suggested change
locationToLocationLink :: Location -> LocationLink
locationToDefinitionLink :: Location -> DefinitionLink

Since you use locationToLocationLink exclusively to create a DefinitionLink.

Copy link
Collaborator

@michaelpj michaelpj left a comment

Choose a reason for hiding this comment

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

I know we don't have tests for any of the other response combination, but if you felt motivated it would be great to start some!

defToLinks (Definition (InR locations)) = map (DefinitionLink . locationToLocationLink) locations

locationToLocationLink :: Location -> LocationLink
locationToLocationLink Location{_uri, _range} = LocationLink{_originSelectionRange = Just _range, _targetUri = _uri, _targetRange = _range, _targetSelectionRange = _range}
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is wrong, originSelectiomRange is quite different and we can't come up with a definition for it, so we should put Nothing.

type Definitions = (Definition |? ([DefinitionLink] |? Null))

mergeDefinitions :: Definitions -> Definitions -> Definitions
mergeDefinitions definitions1 definitions2 = case (definitions1, definitions2) of
Copy link
Collaborator

Choose a reason for hiding this comment

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

There's are client capabilities controlling whether location links are supported. Ideally we should check those and if they're not sent we should instead downgrade the LocationLinks.

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 created a new downgradeLinks function instead and used it to downgrade all LocationLinks in the implementation of combineResponses when required by the missing capability.

@JiriLojda
Copy link
Contributor Author

Thank you both for the review. I will address the comments as soon as possible, most likely this week.

@JiriLojda JiriLojda force-pushed the definition_from_multiple_plugins branch from a3bf0bf to f1a69a5 Compare October 30, 2023 09:11
@JiriLojda
Copy link
Contributor Author

Oh, it seems I was too eager with the new extensions. I thought I could use GHC 9.6 (probably since it is in the snapshot in the default stack.yml). I'll fix that.

Copy link
Collaborator

@michaelpj michaelpj left a comment

Choose a reason for hiding this comment

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

Code looks good, some of this stuff probably belongs in lsp, but we can move that later if we want.

Haven't reviewed the tests yet, but happy to merge regardless.

@michaelpj michaelpj added the merge me Label to trigger pull request merge label Nov 7, 2023
@michaelpj
Copy link
Collaborator

Build failures are genuine.

@fendor fendor removed the merge me Label to trigger pull request merge label Nov 7, 2023
@JiriLojda
Copy link
Contributor Author

I suspect that thanks to the CI cache cabal doesn't know about the focus@1.0.3.2 which is necessary for the build to work on ghc@9.8 (the cause of the previous build failures). I will find a way to clear the cache later.

By the way, do you generally use the cabal-fmt? It is configured to run with stylish-haskell, but all the cabal files I format are completely changed. I commit it anyway because I suppose this is the correct format that we should follow, but I wonder why it wasn't formatted before and also worry that I will cause someone ugly merge conflicts with the changes. :)

@michaelpj
Copy link
Collaborator

CI issues should be worked out, can you fix the conflicts and try again?

@michaelpj
Copy link
Collaborator

Thanks!

@michaelpj michaelpj merged commit 20a37ec into haskell:master Nov 17, 2023
40 checks passed
@JiriLojda
Copy link
Contributor Author

Great, thank you for your help!

@JiriLojda JiriLojda deleted the definition_from_multiple_plugins branch November 17, 2023 09:39
jvanbruegge added a commit to jvanbruegge/haskell-language-server that referenced this pull request Dec 1, 2023
jvanbruegge added a commit to jvanbruegge/haskell-language-server that referenced this pull request Feb 27, 2024
jvanbruegge added a commit to jvanbruegge/haskell-language-server that referenced this pull request Feb 27, 2024
jvanbruegge added a commit to jvanbruegge/haskell-language-server that referenced this pull request Feb 28, 2024
jvanbruegge added a commit to jvanbruegge/haskell-language-server that referenced this pull request Mar 9, 2024
jvanbruegge added a commit to jvanbruegge/haskell-language-server that referenced this pull request Mar 9, 2024
fendor added a commit that referenced this pull request Mar 11, 2024
* hls-notes-plugin: Initial implementation

* hls-notes-plugin: add to feature list and plugin table

* hls-notes-plugin: Add more documentation comments

* hls-notes-plugin: Fix tests after #3846, add CI job

* hls-notes-plugin: Address review comments

* hls-notes-plugin: Allow Note definition within single line comments

* hls-notes-plugin: Improve "Note not found" error message

* hls-notes-plugin: Allow single line notes to be indented

* treewide: Add missing underscores to note definitions

* hls-notes-plugin: Wait until HLS is done in tests

* hls-notes-plugin: Fix tests on windows

The regex did not allow windows line endings in note definitions

---------

Co-authored-by: Jan Hrcek <2716069+jhrcek@users.noreply.github.com>
Co-authored-by: fendor <fendor@users.noreply.github.com>
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.

None yet

3 participants