Add call hierarchy feature

[xster]

Don't know if it's possible. It's possible to check a function's call hierarchy in IntelliJ. Is it possible to bring it to VSCode?

[DanTup]

@bwilkerson I guess this would need support from the analyzer? I can't see anything in the docs that looks like it would provide this.

@xster If we had the data, I'm not sure how we could best display this. We have implemented Type Heirarchy (F4?) but render it in a pick list and I think it looks a bit weird (being a tree in a flat list), see #190 (comment)

[bwilkerson]

By call hierarchy, do you mean a tree where the top-level nodes are all of the methods containing invocations of a selected method, and the children of each node are the methods containing invocations of the parent node?

If so, then it's all done lazily. Each level in the tree is fetched (by searching for references to an element) when the parent node is expanded. It is done this way both for performance and in order to deal with recursive chains of functions. The result isn't strictly a call hierarchy, it's a reference hierarchy, but the distinction is subtle and not interesting to most users.

[DanTup]

Aha, makes sense! I guess we can't wedge it into a picker like we did for types then; it'd have to go in the explorer (tree).

[xster]

I wonder if it's possible to augment the Find all References peek window and make each descendent node also expandable.

[DanTup]

We can't really control this, since Code does all rendering here. However, I think you can do another Find References inside the peek window?

[DanTup]

This makes most sense implemented in VS Code - there's an issue at microsoft/vscode#16110.

[DanTup]

VS Code is adding new APIs for first-class support for this, so this might be possible soon :-)

https://code.visualstudio.com/updates/v1_33#_call-hierarchy

[xster]

I noticed that in the new release notes too. Woohoo!

[DanTup]

@bwilkerson

I was just having a go at implementing this:

If so, then it's all done lazily. Each level in the tree is fetched (by searching for references to an element) when the parent node is expanded

The API in VS Code can call us asking for the "incoming calls" and "outgoing calls" for a node (so you can navigate both ways). I think the incoming calls we could get with search.findElementReferences (the same we use for "Find References") but I'm not sure if there's something that allows us to get the outgoing calls (eg. for a given function, find the calls it makes out to other functions)?

If there's nothing already there, then we could just build this in LSP on the server (rather than add new APIs that we'll migrate away from) once the LSP spec work for this lands.

[bsutton]

Any update on this one.
It's probably the feature I miss the most coming from java/eclipse.

[DanTup]

I have an implementation of this working now. It's not a feature I've really used much myself so I am interested additional testing/feedback once it lands. It's implemented in the Dart SDK (LSP server), so you'd need to use a dev SDK in order for it to show up.

One odd thing I've noticed though is that although we supply the ranges of outbound calls to the client, VS Code doesn't seem to use them. When you click a called method in the tree, VS Code jumps to the declaration and never seems to show you the locations of the outbound calls. There's an open issue about this at microsoft/vscode#111454 which may need 👍 's if that's to be addressed :-)

[bsutton]

So how do I trigger the call hierarchy?

I'm running dart 2.180.271.0.dev
I'm running dartr code 3.44.0
restarted vscode.

I've tried 'find all references'

Screencast.from.18-07-22.12.33.46.webm

[DanTup]

@bsutton v2.180.271.0.dev looks like a branch made for a beta build (see flutter/flutter#107564) and forked before the change above. When using a newer version that does include the change, Call Hierarchy will appear on the context menu:

[bsutton]

@DanTup
Do you have a version no. that you know should work:
I've tried:
2.18.0-263.0.dev
2.18.0-250.0.dev
2.18.0-271.0.dev

none of which show the menu.

[DanTup]

According to the tags shown on the commit, the following versions include it:

• 2.19.0-5.0.dev
• 2.19.0-4.0.dev
• 2.19.0-3.0.dev
• 2.19.0-2.0.dev
• 2.19.0-1.0.dev
• 2.19.0-0.0.dev
• 2.18.0-286.0.dev
• 2.18.0-285.0.dev
• 2.18.0-284.0.dev

I don't know whether those 2.18 dev versions are just automatic tags though. Based on the issue linked above about branching for a beta release (which was before any of those branches), I suspect this change would not show up if that beta branch became a stable 2.18 release, instead being included in a future version.

Note: Right now it seems dart.dev also stops at 2.18.0-271.0.dev which may be because of branching. If you want to test with a bleeding-edge build (not recommended for general production work) there's info here:

https://dart.dev/get-dart/archive#main-channel-url-scheme

For example for macOS:

https://storage.googleapis.com/dart-archive/channels/be/raw/latest/sdk/dartsdk-macos-x64-release.zip for Intel or https://storage.googleapis.com/dart-archive/channels/be/raw/latest/sdk/dartsdk-macos-arm64-release.zip for M1.

[bsutton]

I'm using dswitch to move between dart versions and it only supports the archive channels so this might have to wait until an archive gets released with support. S. Brett Sutton Noojee Contact Solutions 03 8320 8100

…

On Mon, 18 Jul 2022 at 22:53, Danny Tuppeny ***@***.***> wrote: According to the tags shown on the commit <dart-lang/sdk@f34d4d5>, the following versions include it: - 2.19.0-5.0.dev - 2.19.0-4.0.dev - 2.19.0-3.0.dev - 2.19.0-2.0.dev - 2.19.0-1.0.dev - 2.19.0-0.0.dev - 2.18.0-286.0.dev - 2.18.0-285.0.dev - 2.18.0-284.0.dev I don't know whether those 2.18 dev versions are just automatic tags though. Based on the issue linked above about branching for a beta release (which was before any of those branches), I suspect this change would not show up if that beta branch became a stable 2.18 release, instead being included in a future version. Note: Right now it seems dart.dev also stops at 2.18.0-271.0.dev which may be because of branching. If you want to test with a bleeding-edge build (not recommended for general production work) there's info here: https://dart.dev/get-dart/archive#main-channel-url-scheme For example for macOS: https://storage.googleapis.com/dart-archive/channels/be/raw/latest/sdk/dartsdk-macos-x64-release.zip for Intel or https://storage.googleapis.com/dart-archive/channels/be/raw/latest/sdk/dartsdk-macos-arm64-release.zip for M1. — Reply to this email directly, view it on GitHub <#612 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32ODEY6T4AX56S3QSJQDVUVHVNANCNFSM4ESAWSJQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[DanTup]

I'm not sure what "archive channels" means in this context, but FWIW the latest Dart beta on https://dart.dev/get-dart/archive is 2.19.0-255.2.beta which should definitely include it. So if you're able to use beta releases (and not only stable releases) then it should be available.