With this change, tests pass whether we default to server-side or
client-side filtering. Also duplicate a few interesting tests to run
both ways. A future commit will beef up the test coverage for
server-side filtering specifically.
Conflicts:
Sources/SourceKit/sourcekitd/SwiftLanguageServer.swift
* Support for clangd's go-to-definition for header files
- By forwarding the request to clangd when it fails to give
symbol information, we are able to use its built in
go-to-definition support for headers (jump to header file)
* Add static tibs test for clangd go-to-#include
* Move #include test to SourceKitTests and regenerate linux main
* Fix improper escaping of %40 in file URLs
* Add URL escaping test
* Another attempt to fix broken BuildServerBuildSystemTests test on Linux
- URL's `standardizedFileURL` removes trailing slashes from file URLs,
but only on Linux
In preparation for injecting doing more during registration, pass
through the same parameters (add language) so that we can call settings
as necessary.
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.
`SourceKitServer` now talks to the `SwiftLanguageServer` and
`ClangLanguageServerShim` directly through the `ToolchainLanguageServer`
protocol.
Each individual `ToolchainLanguageServer` manages its own threading.
Change-Id: I77aa5468f1486bd4e6e6fdb732c6a051ee05c6d1
Introduce a `BuildSystemDelegate` to handle notifications from the build system
* `SourceKitServer` is the main delegate to process these notifications
* Currently limited to changes in `FileBuildSettings`
* Delegate informs the `BuildSystem` of files to watch via `registerChangeWatching(for: URL)` and `unregisterChangeWatching(for: URL)`
* In the future we could have more integration for handling changes in dependencies
Handling changes in `FileBuildSettings`
* `SourceKitServer` sends notifications to the internal LSPs informing them of any opened documents that have changes in their compiler flags
* For clangd, we send a notification to update the compilation database
* For SourceKit/sourcekitd we must close and reopen the file to force a new AST with the new compiler flags
While we generally want to be type-safe, initialization options is
LSP-server specific, so just use LSPAny so we can pass arbitrary data
through as needed.
Clang looks for the C++ standard headers relative to the clang binary
that we provide in the compilation database. So pass through a real path
so that we get the correct headers.
This builds on the indexer changes to support test projects using the
tibs build system. See the commit message from IndexStoreDB for more
information.
This commit adds a couple of simple tests using test fixtures in the
INPUTS directory. It is a fairly minimal change for using the indexer's
test support code to prove the model works. One missing piece here is
support for mutable sources and updating the index, which is supported
on the IndexStoreDB side, but needs a bit more work here. This also
doesn't include any tests using swiftpm's build system.
