Language-server-protocol: Where are LSIF files used?

[davidanthoff]

I maintain the Julia extension for VS Code, and we have a LS for it. I tried to understand how LSIF fits into this whole picture today, and I'm quite confused :)

In particular, it would be incredibly helpful to understand whether there are existing consumers of these files, where they should be stored and some sort of roadmap for what kind of support for LSIF we can expect inside VS Code.

Here are a couple more specific questions:

• Does the Github PR extension support/uses LSIF dumps? There are various videos showing that, plus the blog post, but it is not clear to me whether that is actually shipping or not? If it is shipping, where does the extension get the LSIF files from?
• In general, are there plans for how these LSIF files are distributed? Or would each language extension be responsible for that itself?
• Will there be native support for LSIF files in VS Code? For example, could our language server respond for a given file with "actually, just use this LSIF file for this file", and then drop out of the picture? In general, how are LS and LSIF supposed to work together?

The general idea of LSIF seems great, but even if we had a indexer for Julia, I don't understand where/how such a file could actually be consumed, used.

Any clarifications on those points would be great.

[creachadair]

N.B.: I don't speak for the LSP maintainers.

To your question about existing consumers of LSIF data, I can offer one datum: I work on the Code Intelligence team at @sourcegraph, and we use LSIF output to provide precise cross-references. While I can't address your questions about the LSIF roadmap, I'll outline my perspective on how LSIF fits into the general picture.

One challenge for language server implementations is that computing accurate answers to code intelligence queries, given only the files in the workspace, can be tricky (due to missing context) or time-consuming. You usually need not only the project's own source files, but also their dependencies. Even in projects where the dependencies are recorded in a lock file, the cost of fetching and indexing is high, and a lot of LS implementations have frustrating performance lacunae as a result. Those issues are further compounded when you want references from _other_ projects as well.

As I see it, the main benefit of LSIF is to support offline indexing: Given an LSIF index for a project, a language server can (or can be taught to) quickly and accurately answer common code intelligence queries like go-to-definition and find references, without having to pay the cost of finding, resolving, fetching, and analyzing a potentially large dependency graph at query time.

Of course, a language server would have to be written (or modified) to support reading LSIF output—and LSIF doesn't _replace_ the role of the language server: An offline index doesn't fully cover code that's being actively changed, for example. But having a good index speeds up the most expensive queries and makes it easier to scale up.

I, also, would be interested to learn more about conventions for managing and processing LSIF output. We have developed our own conventions, but I'm not so far aware of community standards.

Edit: fix typo.

[dbaeumer]

@creachadair thnaks for your great answer. Here are some more code pointers:

• https://github.com/microsoft/lsif-node: LSIF tooling for Node
• https://github.com/microsoft/vscode-lsif-extension: an extension to VS Code to browse LSIF dumps.

[dbaeumer]

I will close the issue due to house keeping. We can still comment and discuss.