Do one of the following for every `FIXME` or `TODO` comment
- Add an issue that tracks the task
- Remove the comment if we are not planning to address it
Change a l public declarations to the `package` access level, accept for:
- The `LanguageServerProtocol` module
- The `BuildServerProtocol` module
- `InProcessClient.InProcessSourceKitLSPClient`
- `LanguageServerProtocolJSONRPC` (I would like to create a more ergonomic API for this like `InProcessSourceKitLSPClient` in the future, but for now, we’ll leave it public)
Unfortunately, our pattern of marking functions as `@_spi(Testing) public` no longer works with the `package` access level because declarations at the `package` access level cannot be marked as SPI. I have decided to just mark these functions as `package`. Alternatives would be:
- Add an underscore to these functions, like we did for functions exposed for testing before the introduction of `SPI`
- Use `@testable` import in the test targets and mark the methods as `internal`
Resolves#1315
rdar://128295618
fix!: remove `documentManager` property
fix!: remove `documentManager` in constructor
fix: added documentManager as a computed Property
fix: remove old documentmanager resetting step
fix!: get throws instead of crashing server
fix: throw ResponseError instead of NSError
fix: adding try & orLog where necesary
fix: refined orLog usage
style: ran swift-format
fix: document being opened twice
fix(DocumentManager): remove unwanted comments
lint: ran swift format
Instead of returning `nil` to indicate that the position conversion failed, log a fault and perform a best-effort recovery.
I think this allows us to perform better recovery and also makes code calling these position conversions a lot simpler because it doesn’t need to make decisions about what to do if position conversions fail.
Instead of logging errors in position translation ad-hoc at the caller’s side (and ofter forgetting to do so), log these errors in `LineTable`. To be able to debug where the position conversion error is coming from, also log the file name and line number of the caller.
rdar://125545620
OSLog is the suggesting logging solution on Apple platforms and we should be using it there, taking advantage of the different log levels and privacy masking.
Switch sourcekit-lsp to use OSLog on Apple platforms and implement a logger that is API-compatible with OSLog for all uses in sourcekit-lsp and which can be used on non-Darwin platforms.
The goal of this commit is to introduce the new logging API. There are still improvements about what we log and we can display more privacy-insensitive information after masking. Those changes will be in follow-up commits.
Add `.swift-format` to the repo and format the repo with `swift-format`.
This commit does not add any automation to enforce formatting of sourcekit-lsp in CI. The goal of this commit is to get the majority of source changes out of the way so that the diff of actually enforcing formatting will have fewer changes or conflicts.
Storing the semantic tokens inside `Document` was an anti-pattern because the semantic tokens only applied to Swift and were also being updated while the document contents themselves stayed constant.
Instead, we should store the semantic tokens in a separate `SemanticTokensManager` that only exists in the `SwiftLanguageServer` and has the sole responsibility of tracking semantic tokens.
This allows us to use Swift concurrency to await the computation of the SwiftSyntax tree for a given document instead of having to poll for its creation.
Re-core the "lexical" token stream on top of SwiftSyntax and call into the parser to (re-)generate these "lexical tokens" when the document changes. Leave the semantic tokens alone since they take some non-zero amount of name lookup to fully resolve references to fully replicate.
When we introduce multiple workspaces, they need to share the same DocumentManager so we don’t accidentally open a Swift file twice in two workspaces that share the same `SwiftLanguageService`. Thus, `SourceKitServer` needs to start owning the document manager.
When we introduce multiple workspaces, they need to share the same DocumentManager so we don’t accidentally open a Swift file twice in two workspaces that share the same `SwiftLanguageService`. Thus, `SourceKitServer` needs to start owning the document manager.
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.
