We would previously fail to correctly build the GNU dependency outputs
on Windows since we were checking the file system representation of the
path against the internal path representation. This fixes the
generation of that command as well as the additional checks in the test
case to allow the test case to succeed on Windows.
Currently `FileSystemError` doesn't have an associated path, which makes diagnosing errors harder. This is going to be fixed in TSC and SwiftPM, but this is a breaking change. Usage of `FileSystemError` is updated in the SourceKit-LSP codebase accordingly.
On Linux, the file handle is closing the file descriptor on deinit
despite `closeOnDealloc: false`
(https://bugs.swift.org/browse/SR-13822). Workaround by keping the
FileHandle alive.
rdar://70995458
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.
* Replaces two logs since those don't result in response messages anymore
* Adds a func for sending messages synchronously, to get the two messages out before fatalError
- 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.
- 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
The libIndexStore and sourcekitdInProc DLLs actually reside in the
binaries directory on Windows. Adjust the paths appropriately for
Windows. This is required to get the libraries to load correctly.
This is just a cleanup change to setup the extensions for other targets.
This allows for platforms to have no extensions or an extension which
may or may not include a `.`.
This adjusts the use of Dispatch to build on Windows. Windows does not
provide `stdout_fileno` and `stderr_fileno`. However, it is possible to
use `fileno` to get the associated fileno from the descriptor.
Dispatch on Windows does not deal with fd's but rather with handles.
Convert the file descriptor to a handle and pass that off to dispatch.
The handle is a non-owning reference, and should not be closed.
Fortunately, dispatch does not close the handle when the DispatchIO is
closed.
- 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.
This is quite important to set otherwise SourceKit-LSP sets off a wrong
package resolution operation potentially resulting in a wrong swiftpm
package graph.
Ideally, SwiftPM should have APIs that don't force clients to handle all
this configuration but we don't have that today.
