- Remove async from workspaceEditAdjustedForCopiedFiles
- Refactor to use uriAdjustedForCopiedFiles helper
- Update dictionary update logic with +=
- Adjust LocationLink creation to use adjusted ranges
- Ensure selectionRange adjustment in prepareCallHierarchy
- Provide default WorkspaceEdit in ClangLanguageService
- Revert asyncMap to map and remove await in SourceKitLSPServer
- Chain workspace and index retrieval in incomingCalls
- Use indexToLSPCallHierarchyItem and shared helper for CallHierarchyItem
- Fix indentation and remove duplicated detail setting
- Use shared helper for TypeHierarchyItem
- Remove .sort() from expected array in tests
- Enable testFindImplementationInCopiedHeader
- Add await for actor-isolated BuildServerManager calls
This addresses issue #2276 by ensuring that all LSP requests that return source file locations
map copied header files back to their original locations, not just jump-to-definition.
Previously, only the definition request applied this mapping. Now, the following requests
also adjust locations for copied files:
- textDocument/references
- textDocument/implementation
- workspace/symbol
- callHierarchy/prepare
- callHierarchy/incomingCalls
- callHierarchy/outgoingCalls
- typeHierarchy/prepare
- typeHierarchy/supertypes
- typeHierarchy/subtypes
This provides consistent navigation behavior, ensuring users are always taken to the original
source files instead of build artifacts when possible.
CMake was previously doing this itself before 4.0, but seems to be
inserting `/usr/bin/*` now. Resolve the `/usr/bin` trampoline ourselves
in a similar fashion to swiftly (but with xcrun).
Resolves rdar://163462990.
Replace usages of `Optional.map` and `Optional.flatMap` by if expressions or other expressions.
I personally find `Optional.map` to be hard to read because `map` implies mapping a collection to me. Usually the alternative constructs seem clearer to me.
If a workspace was opened as `/path/to/workspace` instead of `/path/to/workspace/` (notice the trailing slash), the check for `url.deletingLastPathComponent() == self.projectRoot` failed because deleting the last path component always produces a URL with a trailing slash and URL considers two path different if they mismatch in their trailing slash usage.
Use `DocumentURI` for equality checking, which is a little more lenient with declaring equality, including with regard to trailing slashes, and whose equality definition aligns better with what we want in SourceKit-LSP.
I searched for other usages of `==` between URLs and there doesn’t seem to be any similar issues.
`CompilationDatabaseTests` have been flakey on Windows since
https://github.com/swiftlang/sourcekit-lsp/pull/2334. This didn't really
introduce the failure though - it just added tests that now catch it.
The underlying cause is that `filename.isAbsolutePath` sometimes returns
`true` for a relative path, which then causes the CWD to be prepended
instead of the given `compileCommandsDirectory`.
`PathIsRelativeW` requires a null terminated string, so presumably we
were hitting junk after the initial path that sometimes turned it into
an absolute path. From the Windows docs:
> A pointer to a null-terminated string of maximum length MAX_PATH that
contains the path to search.
Fixes#2360
Resolves rdar://165006835
We previously waited for the initialization response from the build server during the creation of a `Workspace` so that we could create a `SemanticIndexManager` with the index store path etc. that was returned by the `build/initialize` response. This caused all functionality (including syntactic) of SourceKit-LSP to be blocked until the build server was initialized.
Change the computation of the `SemanticIndexManager` and related types to happen in the background so that we can provide functionality that doesn’t rely on the build server immediately.
Fixes#2304
Absolute search paths were being ignored without logging, which makes it
somewhat difficult to diagnose. Log when they're skipped.
Also remove a duplicate options merging block - both
`createWorkspaceWithInferredBuildServer` and `findImplicitWorkspace`
(the only callers of `createWorkspace`) already merge in the workspace
options.
Until we have better measurements that would motivate a different batching strategy, copying the driver’s batch size seems like the most reasonable thing to do.
When I added the log structure to `build/logMessage` in #2022 I must have assumed that the entire BSP notifciation was an extension defined by SourceKit-LSP and didn’t realized that this was actually a change that made the notification non-compliant with BSP. Change it up a little bit to make it compliant again.
If a build server copies files (eg. header) to the build directory during preparation and those copied files are referenced for semantic functionality, we would currently jump to the file in the build directory. Teach SourceKit-LSP about files that are copied during preparation and if we detect that we are jumping to such a file, jump to the original file instead.
So far only the definition request checks the copied file paths. Adding support for copied file paths in the other requests will be a follow-up change.
When the BSP server fails to initialize, it can’t give us any compiler arguments and we won’t be able to provide semantic functionality. Show the message to the user so they can do something about fixing it instead having to dig into SourceKit-LSP logs.