Instead of logging to `stderr`, write log messages to files in `.sourcekit-lsp/logs/sourcekit-lsp-<pid>.<log index>.log`.
This allows us to retrieve the log messages from `sourcekit-lsp diagnose`.
Fixes#1286
rdar://127138318
Implements an initial background index when the project is opened.
The following will be implemented in follow-up PRs:
- Resolving package dependencies
- Preparing dependent modules
- Watching for file updates
Truncate log message after 10.000 characters to avoid flooding the log with huge log messages (eg. from a sourcekitd response). 10.000 characters wasn't chosen because it seems to fit the result of most sourcekitd responses that are not generated interface or global completion results (which are a lot bigger).
Otherwise, the date formatters always output the time in GMT, which has confused me multiple times. Setting the user’s local time zone will emit the date in the user’s local time zone and include the time zone offset to GMT in the date as well.
This allows us to express that `body` will run on the same actor isolation domain as the caller of `orLog`, which effectively makes `orLog` usable from actors again.
I just saw a failure of this test in CI, and can’t figure out what might have happened. Adding some logging that hopefully helps us if the failure happens again.
`os_log` truncates trailing whitespace in a log message. If a chunk containing the file contents ends with a newline, this means that the newline will not get logged and thus the file contents read from the log aren't correct. Append an end marker to each chunk to prevent this trimming.
OSLog only allows the creation of 4000 logger objects, which means that logging will crash on the 4000th request to sourcekit-lsp (which would create the 4000th os_log object because it is the 4000th distinct category in which we are logging).
To circumvent this problem, only use the last two digits of the request and notification ID for the logging scope and wrap around afterwards. This should still allow us to tell apart log messages from concurrently handled requests/notifications while only using 200 os_log objects, which means we stay well clear of the 4000 limit.
rdar://119221355
The changes in #945 changed the dependencies but did not correct them in
the CMakeLists.txt resulting in a broken build. Resynchronise the
dependencies across Package.swift and CMake.
The initializer of `NonDarwinLogLevel` always returned `nil`, even if a valid value was passed. Thus, the log level was always `default`, independent of the value passed to `SOURCEKITLSP_LOG_LEVEL`.
Figuring out where one log message ends and the next one starts is a little tricky. A `---` marker helped me a lot to find the boundary between two log messages.
'swift test' doesn't print os_log output to the command line. Use the `NonDarwinLogger` that prints to stderr so we can view the log output in CI test runs.
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.
The asyncification changes caused some non-deterministic test failures. I believe that some of these are due to race conditions that are the result of the partial transition to actors.
Instead of merging the asyncification piece by piece, I will collect the changes asyncification changes in a branch and then qualify that branch througougly (running CI multiple times) before merging it into `main`.
This adjusts the sourcekit-lsp build to use static linking for the
internal libraries. It is not currently possible to build
SourceKitLSP.dll as that requires re-exporting the interfaces from the
consumed modules. However, this allows us to reduce the overall size of
the distribution of SourceKit-LSP by ~1 MiB and reduces the
distributed file set. The values here assume partial static linking of
swift-package-manager, which helps reduce the total size.
Before:
228,352 BuildServerProtocol.dll
1,773,056 LanguageServerProtocol.dll
114,688 LanguageServerProtocolJSONRPC.dll
49,152 LSPLogging.dll
262,656 SKCore.dll
54,784 SKSupport.dll
80,896 SKSwiftPMWorkspace.dll
150,528 SourceKitD.dll
645,632 SourceKitLSP.dll
70,144 sourcekit-lsp.exe
3,429,888 bytes
After:
2,416,640 sourcekit-lsp.exe
2,416,640 bytes
This will add an additional link request for dispatch and Foundation
libraries. These are really required on non-Darwin targets, and should
be satisfied either by the library search path or by explicitly
indicating where the dependencies can be found.
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.
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.
- clangd itself already logs to stderr so sourcekit-lsp
should do the same for consistency (unless we want to
capture clangd's stderr and forward it in the LSP)
- Editors such as VS Code will show stderr output in the same
output channel where it shows logMessage + traces
Change-Id: Iaf00cffa2e64d8490e21b49a3a9d34a17f54aa9f
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.
