LSIF generation can't be interpreted by 0.6.0 validators

[NTaylorMullen]

Version Used: 4.4.0-1.22372.4

Description:

When LSIF moved to 0.6.0 they introduced a few breaking changes in order to ease the storability of the LSIF format. These breaking changes end up hindering validators from understanding C# output. Some of those breaking changes are:

1. All moniker nodes should have a unique property that specifies its UniquenessLevel.
2. All nodes where the document property was referencing an id of the document containing it got renamed to shard.
3. All project nodes should have a name property on them to indicate what the project name is

Steps to Reproduce:

1. Run LSIF generator on any C# project with content 😄

[jasonmalinowski]

@NTaylorMullen Does the moniker uniqueness replace the older MonikerKind? Or do I still need both?

[jasonmalinowski]

item nodes document property got replaced with shard. Instead of re-specifying what document the shard indicates the id of the document to associate with.

Was this just a rename (effectively) or is there some other newer concept that a 'shard' is invoking here?

[NTaylorMullen]

@NTaylorMullen Does the moniker uniqueness replace the older MonikerKind? Or do I still need both?

kind is now optional. Judging from the docs to me it does look like a replacement.

@dbaeumer am I wrong?

[NTaylorMullen]

item nodes document property got replaced with shard. Instead of re-specifying what document the shard indicates the id of the document to associate with.

Was this just a rename (effectively) or is there some other newer concept that a 'shard' is invoking here?

Was a naming change! And after looking through the docs, it looks like everywhere where document was used as an id reference (references, definition, referenceResults, referenceLInks) it was renamed. I've updated this issue.

[NTaylorMullen]

As an example on how it looks now:

....

[dbaeumer]

@NTaylorMullen Does the moniker uniqueness replace the older MonikerKind? Or do I still need both?

kind is now optional. Judging from the docs to me it does look like a replacement.

No, kind in used to denote if the symbol is import or exported
Uniqueness denote how unique a moniker is: for example a TSC moniker is only unique inside a project since two project can define the same fully qualified name for a symbol. A npm moniker in contrast is globally unique since there can only be one package with name X

[jasonmalinowski]

As far as uniqueness then I think all the monitors we have been generating are at least unique under this:

	/**
	 * The moniker is unique inside the moniker scheme.
	 */
	scheme = 'scheme',

We create two kinds of monikers with two schemes for historical reasons:

1. Ones that are prefixed with the assembly names and then the fully qualified name of the type/member.
2. Ones that represent a namespace, which spreads across all assemblies.

But either of those are unique from the perspective of the .NET type system -- you can't have a project with a duplicate (or at least not in any meaningful way.)

A npm moniker in contrast is globally unique since there can only be one package with name X

@dbaeumer Would that be 'global' or 'scheme' unique? I'd assume there'd be a npm 'scheme' that its' unique under?

[dbaeumer]

@jasonmalinowski thanks for asking that since my last answer was indeed misleading. For npm package we have an npm scheme and these packages are scheme unique. 'global' unique makes IMO only sense if a language uses global unique URIs.

[jasonmalinowski]

@dbaeumer Thanks for confirming, and I think after I made my comment I saw the other description in the LSIF spec that clarified.