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

Call hierarchy support #332

Merged
merged 7 commits into from
May 31, 2021
Merged

Call hierarchy support #332

merged 7 commits into from
May 31, 2021

Conversation

July541
Copy link
Contributor

@July541 July541 commented May 27, 2021

As part of my GSoC 2021 works, this pr adds call hierarchy supporting according to lsp spec.

@jneira
Copy link
Member

jneira commented May 27, 2021

@July541 great work, i'll review it asap
//cc @michaelpj

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.

LGTM, although I'm never sure all the places that need to be updated with capabilities etc!


data CallHierarchyItem =
CallHierarchyItem
{ _name :: Text
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we include haddock corresponding to the doc in the LSP spec for each item? Tedious, but matching the spec is a simple policy and more field documentation is almost always better.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

-- <https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_prepareCallHierarchy>
data CallHierarchyItem = ...

Should it look like this? I have little knowledge about haddock.

lsp-types/src/Language/LSP/Types/CallHierarchy.hs Outdated Show resolved Hide resolved
lsp-test/test/DummyServer.hs Show resolved Hide resolved
@July541
Copy link
Contributor Author

July541 commented May 27, 2021

although I'm never sure all the places that need to be updated with capabilities etc!

It turns out I updated the capabilities following the compile errors/warnings.

@banacorn
Copy link
Contributor

This looks great!
Actually I have a branch with call hierarchy implemented, and I planned to make a PR after #327 is accepted ... It'd be nice it someone can merge it sooner ...

@July541
Copy link
Contributor Author

July541 commented May 28, 2021

@banacorn I am sooo sorry to see about that, I checked the issue list and find no one explicitly intends to do this. To avoid the recurrence of such incidents, I add a comment to make what I'm going to do more public in this repo.

@jneira
Copy link
Member

jneira commented May 28, 2021

Ouch, that is unfortunate indeed, i was not aware of @banacorn plan neither 😟

@July541
Copy link
Contributor Author

July541 commented May 28, 2021

@banacorn I added some missing tests after compared both solutions of you and me, thank you for your inspiration:)

@banacorn
Copy link
Contributor

No, it's not your fault !!
I should've explicitly stated my intent and commented at that issue just like what you've done.
No one on earth would've known what I'm brewing in a secluded branch of my fork.

Anyway, my branch doesn't work. I was actually gonna make a PR and ask for help.
I hit some problem like in #314, none of my call hierarchy handlers are responding to the editor.

@jneira
Copy link
Member

jneira commented May 28, 2021

Ok, what do you think about:

  • @banacorn could review in deep this pr and propose changes (even including code changes that can be commited in the web ui)
  • As @banacorn's branch already has been useful for this one, we would set @banacorn as co-author in the merge commit

@July541
Copy link
Contributor Author

July541 commented May 28, 2021

  • As @banacorn's branch already has been useful for this one, we would set @banacorn as co-author in the merge commit

I agree with this.

@banacorn Out of curiosity, what do you mean about no call hierarchy response? I can navigate the call hierarchy on my client(VSCode) without any explicit configuration.

@banacorn
Copy link
Contributor

@July541 that means it's just broken, as if no call hierarchy supported has been added.
I think I'll get to know what's wrong with my code after reviewing your PR. 🙂

Copy link
Collaborator

@lukel97 lukel97 left a comment

Choose a reason for hiding this comment

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

Hi, I'm not too active here anymore but just chiming in here to say this looks great! Thanks for this PR and I hope you have a great summer of code :)

@July541
Copy link
Contributor Author

July541 commented May 29, 2021

It seems #331 has the same confliction problem that failed on Windows with 8.10.4, I don't have any idea about it for the time being:(

@jneira
Copy link
Member

jneira commented May 29, 2021

will try to take a look in my windows laptop

@jneira
Copy link
Member

jneira commented May 30, 2021

it seems to be a dependency solver issue, related with dependent-map and some, maybe we would need to add some constraints in cabal.project similar to the stack.yaml of his itself

@jneira
Copy link
Member

jneira commented May 30, 2021

I've got to build it adding to cabal.project

constraints: some == 1.0.1,
             dependent-sum == 0.7.1.0

max-backjumps: 10000

But i dont like the workaround

Comment on lines +202 to +204
ResponseResult TextDocumentPrepareCallHierarchy = Maybe (List CallHierarchyItem)
ResponseResult CallHierarchyIncomingCalls = Maybe (List CallHierarchyIncomingCall)
ResponseResult CallHierarchyOutgoingCalls = Maybe (List CallHierarchyOutgoingCall)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the Maybe is not necessary

ResponseResult TextDocumentCallHierarchy     = List CallHierarchyItem
ResponseResult CallHierarchyIncomingCalls    = List CallHierarchyIncomingCall
ResponseResult CallHierarchyOutgoingCalls    = List CallHierarchyOutgoingCall

List should have that null covered

Copy link
Contributor Author

@July541 July541 May 31, 2021

Choose a reason for hiding this comment

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

I just keep it to satisfy the spec. And I still notice that we have several dealings about null, for example:

  1. Use Maybe to represent null.
    ResponseResult TextDocumentHover = Maybe Hover

    https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_hover
  2. Ignore null.
    ResponseResult TextDocumentSignatureHelp = SignatureHelp

    https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_signatureHelp
  3. Strictly follow the spec even like me it looks stupid.
    ResponseResult WorkspaceWorkspaceFolders = Maybe (List WorkspaceFolder)

    https://microsoft.github.io/language-server-protocol/specifications/specification-current/#workspace_workspaceFolders

Maybe we need to unify them under one specific rule.

@jneira
Copy link
Member

jneira commented May 31, 2021

But i dont like the workaround

I dont like it but maybe can be applied to make progress until we have a proper solution

@jneira jneira merged commit 907a697 into haskell:master May 31, 2021
@jneira
Copy link
Member

jneira commented May 31, 2021

Merged! many thanks to @July541 and @banacorn too of course, amazing work

@anka-213
Copy link
Contributor

anka-213 commented Jun 5, 2021

Stupid question, but what is a Call Hierarchy? I couldn't figure it out from the spec, which just seemed to describe the protocol for it, not what the actual thing is.

Edit: Oh, I just saw that the issue this PR is working on fixing explains it: haskell/haskell-language-server#738

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.

6 participants