SwiftPM PR #9985 introduce files in the scratch path whose contents
indicate which build system was used to build artifact for a given build
configuration. if this file exist, use it's contents to infer the build
system. Otherwise, fallback to the existing behaviour.
Fixes: #2576
Binary targets backed by remote `.artifactbundleindex` URLs cause
SwiftPM to re-extract the artifact bundle into the scratch directory
on every package load. The resulting file-change events (delete +
create) for the extracted files triggered another reload, causing an
infinite loop.
Add `isInScratchDirectory` to `fileEventShouldTriggerPackageReload`
to filter out events before the build-settings check. It covers
both the configured scratch directory and the default `.build/`
directory (which receives regular `swift build` output even when
a custom scratch path is configured).
Also add tests using local zip-based binary targets to cover both
the default and custom-scratch-path scenarios. Local zips are used
in the tests to avoid a network dependency; they exercise the same
`isInScratchDirectory` code path even though the infinite loop in
practice requires a remote `.artifactbundleindex` target (where
SwiftPM's checksum mismatch causes re-extraction on every load).
https://github.com/swiftlang/sourcekit-lsp/issues/2615
If we have a source item `include/Test.h` that gets copied to `build/Test.h`, we currently don’t provide any semantic functionality for `build/Test.h`. Improve the build settings fallback logic to construct fallback build settings for `build/Test.h` based on `include/Test.h`.
If the original file does not exist, it is preferable to jump to a file generated by the build system instead of trying to jump to a file that the editor can’t open. This will become important when using the copied file logic to jump to files in `.build/checkouts` instead of `.build/index-build/checkouts` in a follow-up PR.
- 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
Bassam Khouri
Rintaro Ishizaki
Gabe Braden
Alex Hoppen
Kavon Farvardin
Owen Voorhees
loveucifer
Ben Barham
loveucifer
Adam Ward
Anthony Latsis