In certain race condition scenarios, we might receive a document update to which the 0,0 replacetext request returned only syntactic information. In that case we shouldn’t update the sematnic syntax highlighting tokens.
The race condition rarely surfaced as a test failure of `testSemanticMultiEdit`.
I’m not entirely sure when this started occurring but when retrieving folding ranges e.g. for
```
func foo() {
print("someText")
}
```
We report the folding range of `"someText"` twice: Once as the body of the call to `print` and once as the body of the first argument. Each folding range on its own makes sense because you might want to collapse either all arguments or only a single argument. But it doesn’t make sense to report the same range twice.
Implement rudementary support for `DidChangeWatchedFileNotification` for SwiftPM projects: When a file is added, reload the Swift package to compute build settings for it.
This enables proper semantic functionality added to the project after the LSP server was started.
Resolves SR-15633
This adds support for clangd commands for clients which support
dynamic registration (including VS Code), as well as fixes an
issue which prevented clangd's code actions from working.
Also added a test to ensure the clangd code actions work, as well as regenerated the Linux test main (which was missing some other newly added tests).
This is an implementation of LSP's semantic tokens for Swift. Both
lexical and semantic tokens are provided by using the syntaxmap and the
semantic annotations provided as part of SourceKit's open responses and
document update notifications.
While lexical tokens are parsed and stored in the DocumentManager
synchronously, semantic tokens are provided asynchronously. If an edit
occurs, tokens are automatically shifted by the DocumentManager. This is
especially relevant for lexical tokens, which are updated in deltas.
In addition, unit tests are added that assert that both lexical and
semantic tokens are provided and shifted correctly upon edits.
- Add UID for CollectExpressionType request
- Add ExpressionTypeInfo structure
- Add keys to support sourcekitd's CollectExpressionType
- Implement CollectExpressionType request
- Add SwiftLanguageServer.expressionTypeInfos
- Add InlayHint and supporting types
- Add InlayHintsRequest
- Add inlayHints handler stub
- Implement inlay hints request
- Update InlayHint to follow the current proposal
- # This is the commit message #11:
- ...as described in the LSP proposal
- Update doc comment on InlayHintsRequest
- Map inlay hints lazily
- Fix minor style issue
- Add new files to CMakeLists.txt
- Specify commit of the current inlay hints proposal state
- Add public, memberwise initializer for InlayHintsRequest
- assert(false) if deserializing ExpressionTypeInfos fails
- Add dispatch precondition to _expressionTypeInfos
- Add InlayHintsRequest to the builtinRequests
- Factor out function for querying document symbols for URI
- Only render inlay hints after variable bindings
- Test inlay hints on empty document
- Test inlay hints for some simple bindings
- Test ranged inlay hint requests
- Make sure that inlay hints are unique per position
- Test inlay hints for fields
- Apply various PR suggestions regarding inlay hints
- Update inlay hint tests and add case with explicit type annotations
- Continue iterating if an ExpressionTypeInfo fails to deserialize
Correct the polarity of the check. The path being a UNC path or having a drive letter indicates that it *is* a path, as opposed to the inverted representation that was accidentally committed.
This corrects the path identification to include Windows paths properly.
Although this is not entirely ideal due to the platform specific code,
but avoids crashing the SourceKit LSP server if it encounters a space in
the path.
- Add LSP types for semantic highlighting
- Limited to clients which support dynamic registration for semantic highlighting
- Requires clangd 11 or later
Using dynamic registration (when supported by the client) allows
us to provide different completion options for ObjC and Swift
files.
We should be able to expand this to other capabilities in the future
(e.g. semantic highlighting, execute command support).
A number of tests were failing with the -Onone lifetime changes.
Regardless of what happens with that change, I'd like to keep our tests
passing with the stricter rules since we also test in release builds.
This actually addresses the real issue that was ignored earlier about
pipes on Windows. The FileHandle cannot provide a non-owning file
descriptor (the returned file descriptor would need to be explicitly
`_close`'d by the receiver). Foundation now vends a `_handle` accessor
to the OS primitive handle. Use this to create the dispatch loop for
messaging. We now create the JSONRPCConnection from handles on Windows
which actually should help enable running some of the tests on Windows
as well.
- Fix for https://bugs.swift.org/browse/SR-13561 by making sure the
session close waits for the open to finish
- Add a regression test
Change-Id: Iff7217d7b03bc797e036c5329afb0765dcc1874b
- Don't log entire LSP notifications/requests for the `info` level, instead log of the form:
- `Notification<method>` e.g. Notification<textDocument/publishDiagnostics>
- `Request<method(id)>` e.g. Request<textDocument/hover(6)>
- `Response<method(id)` e.g. Response<textDocument/hover(6)>
- Only log sourcekitd requests/responses at the debug level
This allows building without dispatch and Foundation build roots, which
allows for a multi-phase build. This is intended to support the Windows
staged build where dispatch and Foundation are part of the SDK and
SourceKit-LSP is part of the devtools.
- Avoid short queries (< 3 characters) since they are slow and noisy. Xcode does the same thing.
- Limit the number of results returned:
- Improves performance for queries which match many symbols
- Currently take the first N results to improve performance for large projects
but once we support cancellation we should take the top N.
