Add support for Call Hierarchies in language server #35176

rbuckton · 2019-11-19T00:02:24Z

This adds support for Call Hierarchies in the TypeScript language service and tsserver.

A Call Hierarchy can be requested on any "callable" named declaration:

Class Declarations
Class Expressions (with a name or assigned to a const variable)
Function Declarations
Function Expressions (with a name or assigned to a const variable)
Arrow Functions (assigned to a const variable)
Methods
Accessors

The call hierarchy item for a constructor is currently resolved as its containing class.

Incoming and outgoing calls to a Call Hierarchy item are inferred from the following call sites:

CallExpression (i.e. foo())
NewExpression (i.e. new C())
TaggedTemplateExpression (i.e. foo`tmpl`)
Property/element access on an accessor (i.e. obj.a)
Decorators (i.e. @foo class C { })
Jsx Elements (i.e. <MyCustomElement />)

Fixes #31863

typescript-bot · 2019-11-19T00:02:27Z

Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping @sheetalkamat, @amcasey, @mjbvz, @minestarks for you. Feel free to loop in other consumers/maintainers if necessary

rbuckton · 2019-11-19T00:19:15Z

@mjbvz, @jrieken: I have an implementation of the TypeScript language feature for this for VS Code as well. I can submit a PR once this is shipping in a nightly.

uniqueiniquity · 2019-11-25T22:05:17Z

What's the intent of the "prepare call hierarchy" command being distinct from the "callers" and "callees" commands?

rbuckton · 2019-11-25T22:20:04Z

@uniqueiniquity a few reasons:

This mirrors the VSCode API (including the LSP API).
The language client can resolve the same call hierarchy item from multiple locations (the declaration and any reference to that declaration), without requesting the full set of results. It can use that information to maintain a cache of incoming/outgoing calls without needing to request all of the data for every location.

uniqueiniquity · 2019-11-25T22:23:23Z

@rbuckton Makes sense to me - I wanted to make sure I understood fully.
My priority is making sure that this API stays aligned/compatible with what's likely to end up being the LSP equivalent, and the current proposal didn't seem to have the same notion of a distinct preparation command.

rbuckton · 2019-11-25T22:39:11Z

As I understand it, this is the official VS Code API: microsoft/vscode#70231 (comment). There may be some differences with the LSP API

uniqueiniquity · 2019-11-25T22:43:17Z

Ah, thanks for the pointer. Looks like LSP is appropriately looped in so that everything ends up aligned. Thanks!

rbuckton · 2019-11-25T22:43:40Z

The LSP API is similar: https://github.com/microsoft/vscode-languageserver-node/blob/master/protocol/src/protocol.callHierarchy.proposed.md

uniqueiniquity · 2019-11-25T22:44:48Z

Yeah that's the proposal I linked earlier. It seems like the prepare call hasn't ended up there yet, but seems likely that it will before being finalized based on the input from you and VS Code.

rbuckton · 2019-11-25T22:45:05Z

The API for the protocol is here: https://github.com/microsoft/vscode-languageserver-node/blob/0c46b297f8d1a6720edff43ba1618498108c098d/protocol/src/protocol.callHierarchy.proposed.ts#L122-L132

export interface CallHierarchyPrepareParams extends TextDocumentPositionParams, WorkDoneProgressParams {
}

export namespace CallHierarchyPrepareRequest {
	export const type = new RequestType<CallHierarchyPrepareParams, CallHierarchyItem | null, void, CallHierarchyRegistrationOptions>('textDocument/prepareCallHierarchy');
	export type HandlerSignature = RequestHandler<CallHierarchyPrepareParams, CallHierarchyItem | null, void>;
}

export interface CallHierarchyIncomingCallsParams extends WorkDoneProgressParams, PartialResultParams {
	item: CallHierarchyItem;
}

rbuckton · 2019-11-25T22:45:54Z

I think the md file is 8 months out of date compared to the actual API.

# Conflicts: # src/harness/fourslashImpl.ts # src/services/utilities.ts

andrewbranch

So the call hierarchy only goes one level up (incoming) and one level down (outgoing), right?

Is your VS Code PR up yet? It would be cool to see this in action.

andrewbranch · 2019-12-13T21:59:48Z

src/services/utilities.ts

@@ -259,6 +290,10 @@ namespace ts {
        return node && node.parent && node.parent.kind === SyntaxKind.PropertyAccessExpression && (<PropertyAccessExpression>node.parent).name === node;
    }

+    export function isArgumentExpressionOfElementAccess(node: Node) {
+        return node && node.parent && node.parent.kind === SyntaxKind.ElementAccessExpression && (<ElementAccessExpression>node.parent).argumentExpression === node;


Can node actually be falsey, and if so why isn’t it typed that way?

No optional chain? 😁

I started this before optional chaining went in

Also, isArgumentExpressionOfElementAccess was derived from the isRightSideOfPropertyAccess function just above it.

rbuckton

VS Code PR is actually waiting on this to ship in a nightly.

weswigham · 2019-12-17T23:14:46Z

tests/cases/fourslash/callHierarchyFunction.ts

+] = test.ranges();
+
+goTo.marker();
+verify.callHierarchy({


So, hear me out, might it be nicer to baseline a graphical representation of the call heirarchy results, rather than all this explicit, manual shaping?

Something like verify.callHierarchy() which dumps

//// [/tests/cases/fourslash/callHeirarchyFunction.ts] [r1|function [r2|foo|]() { [r3|bar|](); }|] [r4|function /**/[r5|bar|]() { [r6|baz|](); [r7|quxx|](); [r8|baz|](); }|] [r9|function [r10|baz|]() { }|] [r11|function [r12|quxx|]() { }|] //// [query result] ┏⮞ (function) foo ┃ name: r2 ┃ selection: r1 ┃ references: r3 ┗┳⮞ (function) bar (selected) ┃ name: r5 ┃ selection: r4 ┗┳⮞ (function) baz ┃ name: r10 ┃ selection: r9 ┃ references: r6, r8 ┗⮞ (function) quxx name: r12 selection: r11 references: r7

or something else like what the editor would show for the query into a baseline file? So the test file can just be

/// <reference path="fourslash.ts" /> //// function foo() { //// bar(); //// } //// //// function /**/bar() { //// baz(); //// quxx(); //// baz(); //// } //// //// function baz() { //// } //// //// function quxx() { //// } goTo.marker(); verify.callHierarchy();

I've switched the tests to baselines. Let me know what you think of the output format. Since I'm not using them anymore, should I just go ahead and get rid of the old verifyCallHierarchy... methods?

Yeah, I guess so. I like the baseline format, but it could do with being a bit more... compact/diffable. I liked what I suggested above because the query result is pretty close to what the editor displays for the query (albeit with text instead of an icon for the kind), plus a bit of markup to link it back to the generated spans.

The arrows don't show well in beyond compare, unfortunately. I also think the way I'm highlighting spans is easier to read than [r1|function|] etc.

src/server/session.ts

rbuckton · 2019-12-20T20:20:48Z

@uniqueiniquity, @weswigham: Any other comments? I'd like to get this in soon so I can put up a PR for VS Code as well.

src/server/session.ts

rbuckton requested review from andrewbranch, RyanCavanaugh and sheetalkamat November 19, 2019 00:02

rbuckton force-pushed the callHierarchy branch from 9559aaf to 92c102e Compare November 19, 2019 00:14

Add support for Call Hierarchies in language server

4ca40ce

rbuckton force-pushed the callHierarchy branch from 92c102e to 4ca40ce Compare November 19, 2019 00:33

Merge branch 'master' into callHierarchy

d957ef6

# Conflicts: # src/harness/fourslashImpl.ts # src/services/utilities.ts

andrewbranch reviewed Dec 13, 2019

View reviewed changes

rbuckton requested review from weswigham and sandersn December 17, 2019 21:14

rbuckton commented Dec 17, 2019

View reviewed changes

weswigham reviewed Dec 17, 2019

View reviewed changes

src/server/session.ts Outdated Show resolved Hide resolved

rbuckton added 4 commits December 18, 2019 15:05

Use baselines for callHierarchy tests

64351ee

Clean up commented code

93e93f7

Support multiple hierarchy items when an implementation can't be found

e0cedbe

Use optional chaining in a few places

b51fb31

uniqueiniquity reviewed Dec 21, 2019

View reviewed changes

src/server/session.ts Outdated Show resolved Hide resolved

weswigham approved these changes Dec 21, 2019

View reviewed changes

Use getFileAndProject

c01d40a

rbuckton merged commit 6c413e0 into master Dec 22, 2019

rbuckton deleted the callHierarchy branch December 22, 2019 21:25

rbuckton mentioned this pull request Jan 6, 2020

Add call hierarchy support for TypeScript 3.8 microsoft/vscode#88168

Merged

MattSPalmer mentioned this pull request Mar 10, 2020

Support call hierarchies neoclide/coc-tsserver#128

Closed

nfrid mentioned this pull request Dec 15, 2022

Call Hierarchy on tsserver neovim/nvim-lspconfig#2317

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for Call Hierarchies in language server #35176

Add support for Call Hierarchies in language server #35176

rbuckton commented Nov 19, 2019

typescript-bot commented Nov 19, 2019

rbuckton commented Nov 19, 2019

uniqueiniquity commented Nov 25, 2019

rbuckton commented Nov 25, 2019

uniqueiniquity commented Nov 25, 2019

rbuckton commented Nov 25, 2019

uniqueiniquity commented Nov 25, 2019

rbuckton commented Nov 25, 2019

uniqueiniquity commented Nov 25, 2019

rbuckton commented Nov 25, 2019

rbuckton commented Nov 25, 2019

andrewbranch left a comment

andrewbranch Dec 13, 2019

rbuckton Dec 17, 2019

rbuckton Dec 19, 2019

rbuckton left a comment

weswigham Dec 17, 2019 •

edited

Loading

rbuckton Dec 18, 2019

weswigham Dec 19, 2019 •

edited

Loading

rbuckton Dec 20, 2019

rbuckton commented Dec 20, 2019

Add support for Call Hierarchies in language server #35176

Add support for Call Hierarchies in language server #35176

Conversation

rbuckton commented Nov 19, 2019

typescript-bot commented Nov 19, 2019

rbuckton commented Nov 19, 2019

uniqueiniquity commented Nov 25, 2019

rbuckton commented Nov 25, 2019

uniqueiniquity commented Nov 25, 2019

rbuckton commented Nov 25, 2019

uniqueiniquity commented Nov 25, 2019

rbuckton commented Nov 25, 2019

uniqueiniquity commented Nov 25, 2019

rbuckton commented Nov 25, 2019

rbuckton commented Nov 25, 2019

andrewbranch left a comment

Choose a reason for hiding this comment

andrewbranch Dec 13, 2019

Choose a reason for hiding this comment

rbuckton Dec 17, 2019

Choose a reason for hiding this comment

rbuckton Dec 19, 2019

Choose a reason for hiding this comment

rbuckton left a comment

Choose a reason for hiding this comment

weswigham Dec 17, 2019 • edited Loading

Choose a reason for hiding this comment

rbuckton Dec 18, 2019

Choose a reason for hiding this comment

weswigham Dec 19, 2019 • edited Loading

Choose a reason for hiding this comment

rbuckton Dec 20, 2019

Choose a reason for hiding this comment

rbuckton commented Dec 20, 2019

weswigham Dec 17, 2019 •

edited

Loading

weswigham Dec 19, 2019 •

edited

Loading