By default, print 1-based line/column numbers using the defacto standard
line:column format. In debug print, continue to use the 0-based values
to match the constructor.
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
Work in progress: add a basic implementation for keeping track of the
current completion session, and use the sourcekitd
complete.open/update/close requests.
Conflicts:
Sources/SourceKit/sourcekitd/CodeCompletion.swift
Sources/SourceKit/sourcekitd/SwiftLanguageServer.swift
Similar to cursor info, there is enough code here it makes sense to
separate it out.
Conflicts:
Sources/SourceKit/sourcekitd/CodeCompletion.swift
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
Specifically, we care that all outstanding **writes** are finished
before we call the close handler, because otherwise we may (a) send
corrupted output during shutdown, or (b) drop notifications and replies
sent during the shutdown process. The former is a potential issue for
clients that are not robust about parse failures, and the latter is an
issue for reproducibility and robustness during testing/debugging - in
particular, we have some integration tests that send data without
waiting for individual replies and they need to finish outstanding
replies before exiting.
rdar://60159448
This avoids having a gotcha in the API where if a build system calls
these methods while it is being called back for settings or to register
for notifications it deadlocks (or crashes in libdispatch to prevent the
deadlock).
If we unregisted a file for settings and subsequently received a
settings changed notification that contained that file, we would drop
all of the *other* settings changes delivered in the same call.
- 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
- Add support for recently upstreamed `forceRebuild` extension (6ff0228c6d).
Note that until it is merged into Apple-clangd we can't add a test for it with missing headers
- Add a test for the clangd functionality by modifying a generated header file
Change-Id: If53fd88da92e4fc7d9c22af7430300fb3fc0f5ce
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.
The client guarantees that unsupported kinds will be handled, and in
practice some clients, such as Sublime's LSP plugin, use
`"codeActionKind":{"valueSet":[]}`, since they support all kinds anyway.
This behaviour was also clarified in a [spec issue
report](https://github.com/Microsoft/language-server-protocol/issues/620)
where it was confirmed the server can send any actions it wants. It
seems preferable to ignore it.
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.
The JSON compilation database allows specifying arguments either as an
array of string ("arguments") or as a single shell-escaped string
("command"). When using "command", we were hitting very slow load times
for large compilation databases. This commit speeds up splitting the
shell-escaped command by not iterating the UTF-8 view instead of the
graphemes.
In release builds I see ~10x speedup of the splitting perf test, and
~3-5x in a debug build. In a real-world test using the cmake-generated
compile_commands.json for llvm+clang this sped up overall compilation
database loading from 11 seconds to 1.2 seconds on my machine.
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.
