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

CallHierarchy support #48

Open
jbellis opened this issue Jan 26, 2025 · 6 comments
Open

CallHierarchy support #48

jbellis opened this issue Jan 26, 2025 · 6 comments

Comments

@jbellis
Copy link

jbellis commented Jan 26, 2025

Hi there and thanks for creating multilspy!

I'm using it to create a language-agnostic-ish call graph to solve LLM code assistant context. [Article.]

Currently this is two passes:

  1. Forward pass through request_document_symbols to collect method regions
  2. For each symbol, call request_references and add edges

(1) is about 0.1s per file which is not great but I can live with it. But (2) is about 2.5s per source file.

Multithreading helps a little but not much (about a factor of 2x), because Python.

I think I could do (2) in request-per-file instead of request-per-symbol if I had CallHierarchy with outgoingCalls support.

WDYT?

@LakshyAAAgrawal
Copy link
Collaborator

@jbellis
Copy link
Author

jbellis commented Jan 26, 2025

Yes

@jbellis
Copy link
Author

jbellis commented Jan 26, 2025

the other nice thing about structuring it around outgoingCalls instead of request_references is you can easily rebuild just a single node when a method gets edited

@LakshyAAAgrawal
Copy link
Collaborator

@jbellis could you please see if #47 helps?

@LakshyAAAgrawal
Copy link
Collaborator

Further, one feature of multilspy that I personally like is that it is very easy to access the underlying language server connection handler. This means, it is very easy to use a lsp feature that hasn't been implemented as a first class feature in multilspy.

Please refer to detailed steps I shared about it in another related thread (#12 (comment)). This isn't to discourage new feature requests, but so that multilspy users can get started with using the features they want, till a detailed implementation of it can be integrated first-class into multilspy.

Please let me know if you have any questions!

@jbellis
Copy link
Author

jbellis commented Jan 27, 2025

Good timing with #47 -- it will be easy to add outgoing calls on top of 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

No branches or pull requests

2 participants