Add isDefinition to references

[sandersn]

This allows clients to distinguish definitions from usages. I used this to change tide to behave more like Resharper: tide-references now jumps directly to a single usage if only one usage and one definition exist. For example,

function f() {
  const once/*1*/ = 12;
  const twice/*2*/ = 13;
  const thrice/*3*/ = twice + 1;
  return once + twice + thrice + thrice + thrice;
}

If you get all references at /1/, you'll jump straight to the return line. If you get all references at /2/, you'll get the normal buffer listing references. Because of the deduping logic I wrote for tide, /3/ will behave the same as /1/ since all references are on the same line. But that's not necessarily the right thing.

@Andy-MS I believe you were interested in this for Sublime too. @zhengbli, can you look at this and say whether it's the right approach?

[mhegazy]

undefined otherwise?

[mhegazy]

sorry looking at the code below, it is always set, so why make it optional?

[sandersn]

I thought it was necessary for API additions. I'll make it required if that's not the case.

[mhegazy]

i would add a test for a binding pattern, import/export, string literal names property, computed property, and numeric named property.

[mhegazy]

why not push this into isDeclarationName ?

[sandersn]

it's not true all the time -- isDeclarationName additionally checks that node.parent.name === node which needs to be generally true for something to be a valid declaration. Computed property names don't meet this requirement because often we can't calculate the name at compile time. In this code path, however, we know that the computed property name already, so I added the special case here only .

[sandersn]

I tried pushing it further, but computed property's symbols started disappearing from our symbol baselines. I did discover isLiteralCompuatedPropertyDeclarationName, so I switched to that instead of the direct check of SyntaxKind.

[mhegazy]

👍