Add way to differentiate references for definitions at requesting location

[mjbvz]

Bug Report

🔎 Search Terms

• references
• find all references

Problem

We use the references request to power VS Code's references code lens feature. References returned by TS have an optional isDefinition property that tells if the reference is to a definition or not. We use this to avoid showing multiple references for a case such as:

function foo(a: number): number;
function foo(a: string): string;
function foo(a: string | number): string | number;

The references code lens basically just filtered out any references that are marked isDefinition

However this also prevents us from showing the correct reference count in cases such as:

interface IFoo {
    foo(): void;
}

class Foo implements IFoo {
    foo(): void { }
}

In this case, the two references to foo should have 1 reference, but we show 0 references because both references are definitions.

microsoft/vscode#117021 shows another case with object literal shortcut

Proposal

We'd like a new property on the references response that tells us if the reference belongs to definition from the requesting location (not yet sure what the name of this should be).

For a case with overloads such as:

function foo(a: number): number;
function foo(a: string): string;
function foo(a: string | number): string | number;

If we request references on any of the calls to foo, this new property would be marked true. However it would not be true in cases such as:

export const foo = 123;

console.log({ foo });

or:

interface IFoo {
    foo(): void;
}

class Foo implements IFoo {
    foo(): void { }
}

[mjbvz]

I'm also open for alternative proposals on how to handle this. The main issue is that can't handle these cases reliably on the VS Code side today for the references code lens, and would like to improve this

[DanielRosenwasser]

Let's chat about this on Wednesday at the next editor sync.

const foo = 123;
console.log({ foo });

This is a great test case, but it also maybe speaks to how we name things here.

[DanielRosenwasser]

One of the ideas here was to instead add an argument to the find-all-references request, and the language server could do the filtering on its own side. Naming will still be weird/hard here.

[mjbvz]

I'm going to mark this as a VS Code priority since it is a pretty annoying papercut. We still need to finalize the names in the api but I think agreed that the general concept of this api makes sense

This would be for the 4.4 timeframe, not for the current 4.3 release