- Otherwise can lead to confusing duplicated diagnostics in VSCode
due to its usage of virtual documents for source control diffbases
- sourcekitd does not properly handle virtual files when the
`-working-directory` flag is passed
Change-Id: I9b7f435aac3f7c19082dd6c2fd7561c524356352
We were treating arrays of fixits as if they were independent actions,
but in reality we have at most one quick-fix per diagnostic, which is
composed of multiple edits. This fixes cases like renaming a deprecated
method where there are multiple edits that need to be combined.
While the diagnostic provides the broader context, there can be multiple
fixits and it is helpful to give some way to see what they will do. This
adds a brief "Insert ';'", "Replace 'let a' with '_'", "Remove 'blah'"
description as the title.
The build system manager will integrate with the indexer to provide
header to main file mappings, including keeping those mappings
up-to-date as `#include`s are added and removed. This allows us to
provide accurate compiler arguments for a header based on a real
translation unit. When there are no main files found, we continue to
fallback to asking the build system.
The build system manager also gives us a place to put a client-side
setting cache, since multiple headers may map to a single main file.
For now, the BuildSystemManager is only used by tests. A subsequent
commit will wire it up to the index and server.
In preparation for injecting doing more during registration, pass
through the same parameters (add language) so that we can call settings
as necessary.
Introduce types for looking up and receiving notifications about changes
to main file mappings (e.g. header.h -> foo.cpp) in terms of documents.
For now this is only exercised in the test, but the goal is to use this
to correctly lookup main files for headers during build system queries.
Some editors treat the initialize request as blocking, or otherwise time
out if it takes too long. We have been scraping that edge for swiftpm
projects (time taken to load the manifest and construct a build graph),
and large compilation databases (time taken to parse the json and then
split commands into separate arguments). In practice, a *debug build* of
sourcekit-lsp was failing to open a large compilation database fast
enough for sublime text's lsp plugin (3 second limit).
This change hides the latency for loading the build system and creating
the index by letting it continue beyond the initialize request, blocking
instead the next request. This is not a complete solution. In addition
to hiding latency in between requests, this also is based on editors
being more forgiving about slow requests beyond the first initialize.`
We should also continue to improve the performance of the initial load
of the build system and index. And we should also consider more
prinicipled ways to use asynchronicity, for example by not doing the
initial load on the server's message queue. The main challenge for that
is that we have some assumptions, particularly in tests, that the index
will be created already, and for the index to load we currently block on
the build system load in order to get the index directory.
Find the index store path by searching through the command-line
arguments, and if found, also provide a default database path next to
the index store. Also add command-line arguments so that either of these
can be overridden. We could also easily add these as initialization
options if an LSP client wanted to provide them in the future.
Request types should always have the suffix Request and notifications
should end with Notification.
Also moved all request and notification types into separate folders to
reduce the number of files in the LanguageServerProtocol folder.
Not all editors send shutdown/exit messages, particularly when you quit
the application (as opposed to a single editor window), so we sprinkle
`prepareForShutdown()` into the connection closed handler as well. I
verified manually in such an editor that this lets us save the index on
quit.
If the client is well-behaved and sends a shutdown request, we close the
index in order to flush it to disk. This should speed up reopening the
same project when it is already indexed.
URL can in fact store URIs, it just doesn't have a very nice API to
interact with them. As long as we only operate on absoluteString, we
should be fine though. So instead of implementing the logic for
detecting file URLs ourselves, we can just use a URL as storage for
DocumentURI.
According to the LSP specification, arbitrary URIs can be used as
document identifiers. Instead of internally assuming that all URIs are
URLs, use a DocumentURI enum to represent URIs. These can either be file
URLs or other URIs whose value as treated as an opaque string.
We will be able to split the LSP modules off later. These LSP modules
will provide the ability to write custom LSP servers and clients in
Swift. The sourcekit-lsp repository will build on top of this new
package to provide an LSP implementation that creates a language server
for Swift and C-based-languages.
