apple / sourcekit-lsp Goto Github PK

Language Server Protocol implementation for Swift and C-based languages

License: Apache License 2.0

Swift 97.42% C 0.53% Python 1.35% CMake 0.70%

sourcekit-lsp's Introduction

SourceKit-LSP

SourceKit-LSP is an implementation of the Language Server Protocol (LSP) for Swift and C-based languages. It provides features like code-completion and jump-to-definition to editors that support LSP. SourceKit-LSP is built on top of sourcekitd and clangd for high-fidelity language support, and provides a powerful source code index as well as cross-language support. SourceKit-LSP supports projects that use the Swift Package Manager.

Getting Started

The SourceKit-LSP server is included with the Swift toolchain. Depending on how you installed Swift, you may already have SourceKit-LSP. Make sure you build your package with the same toolchain as you use sourcekit-lsp from to ensure compatibility.

Get SourceKit-LSP with a Swift toolchain
1. If you have installed Xcode 11.4+ or the corresponding Command Line Tools package, the SourceKit-LSP server is included and can be run with xcrun sourcekit-lsp.
2. If you are using a toolchain from Swift.org, the SourceKit-LSP server is included and can be run with xcrun --toolchain swift sourcekit-lsp on macOS, or using the full path to the sourcekit-lsp executable on Linux.
3. If your toolchain did not come with SourceKit-LSP, see Development for how to build it from source.
Configure your editor to use SourceKit-LSP. See Editors for more information about editor integration.
Build the project you are working on with swift build using the same toolchain as the SourceKit-LSP server. The language server depends on the build to provide module dependencies and to update the global index.

Development

For more information about developing SourceKit-LSP itself, see Development. For information about developing SourceKit-LSP clients (like editors or their language plugins), see Client Development.

Indexing While Building

SourceKit-LSP uses a global index called IndexStoreDB to provide features that cross file or module boundaries, such as jump-to-definition or find-references. To efficiently create an index of your source code we use a technique called "indexing while building". When the project is compiled for debugging using swift build, the compiler (swiftc or clang) automatically produces additional raw index data that is read by our indexer. Producing this information during compilation saves work and ensures that any time the project is built the index is updated and fully accurate.

In the future we intend to also provide automatic background indexing so that we can update the index in between builds or to include code that's not always built like unit tests. In the meantime, building your project should bring our index up to date.

Status

SourceKit-LSP is still in early development, so you may run into rough edges with any of the features. The following table shows the status of various features when using the latest development toolchain snapshot. See Caveats for important known issues you may run into.

Feature	Status	Notes
Swift	✅
C/C++/ObjC	✅	Uses clangd
Code completion	✅
Quick Help (Hover)	✅
Diagnostics	✅
Fix-its	✅
Jump to Definition	✅
Find References	✅
Background Indexing	❌	Build project to update the index using Indexing While Building
Workspace Symbols	✅
Rename	❌
Local Refactoring	✅
Formatting	✅	Whole file only
Folding	✅
Syntax Highlighting	✅	Both syntactic and semantic tokens
Document Symbols	✅
Call Hierarchy	✅
Type Hierarchy	✅

Caveats

SourceKit-LSP does not update its global index in the background, but instead relies on indexing-while-building to provide data. This only affects global queries like find-references and jump-to-definition.
- Workaround: build the project to update the index

sourcekit-lsp's People

Contributors

Stargazers

Watchers

Forkers

benlangmuir shyamalschandra gmittert xwu ainopara fscpro danielmartin wickedlynx nghiatranuit dierksen alvincrisuy bb-apple adamnemecek shaunstanislauslau devhttps spencerx ishkawa akyrtzi rintaro yhkaplan rockbruno enterstudio tylerc230 nzatsepilov firehed jonarrien dduan anatolicvs davidgoldman tonyle9 spikeleehom dalavancloud gayashanbc zeroinfinite nickset mackoj fwcd aciidgh lk251 rabingaire tomerd jate weissi dkiszkiel trzyipolkostkicukru kateinoigakukun phamphiphuc quntion adapter00 wongzigii jameshartt gabrielpeart firecrackerz lovishdogra dinneo nathawes jradams hyp ghostsofhiroshima literalpie microhexhq rmaz fredriksjoberg millenomi mrmersinlioglu vigneshvelusamy svenlauterbach pondok-programmer nomuq eonil alanquatermain ikesyo lucianopalmeida swift-embedded adellibovi ghvg1313 szamarri kuwerty tachoknight bioshrek finagolfin cathy1223lin ahoppen sgguo compnerd youngshingjun nikolay-pv linwenquan abaelhe klaaspieter shekhar-rajak merisbahti florg1 hartbit joeho80 michaelsabo mpapple-swift kevleyski imcho zlproject89

sourcekit-lsp's Issues

[SR-11276] Sourcekit-LSP returns wrong position for protocol method implementations


Previous ID	SR-11276
Radar	None
Original Reporter	cukier (JIRA User)
Type	Bug

Environment

commit c0d2ad0 of sourcekit-lsp

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 1f8f35a85d2991c3ff9d52e044c6482d

Issue Description:

protocol Aaa { 
    func bbb()
}
class Ccc { 
    func bbb() { } //5
}
extension Ccc: Aaa { } //7
class Ddd: Ccc { } //8

If you ask for implementations for function `bbb` in the protocol, Sourcekit-LSP will return positions at lines 7 and 8. I would expect it to return the position of the method at line 5.

[SR-14658] generated bundle is not indexed by SK-LSP


Previous ID	SR-14658
Radar	None
Original Reporter	@compnerd
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 8e4e418d2a71ce0452bc6752177d2eee

Issue Description:

When using a project in a SPMWorkspace with SK-LSP, the generated bundle resource is not indexed:

#if SWIFT_PACKAGE
let _ = Bundle.module
#endif

[SR-10809] Honour ClientCapabilities for code completion snippets


Previous ID	SR-10809
Radar	None
Original Reporter	@benlangmuir
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug, StarterBug
Assignee	rockbruno (JIRA)
Priority	Medium

md5: 9dd1bf0b87599da59d5dbf4174138ac3

Issue Description:

We currently always return code-completion items with snippets. However, this is supposed to be configurable by the client/editor using

TextDocumentClientCapabilities
> completion
> completionItem
> snippetSupport

https://microsoft.github.io/language-server-protocol/specification#initialize

We should honour that capability, and when the editor does not support snippets, strip them out before returning the completion.

[SR-15058] Compute document semantic tokens on demand


Previous ID	SR-15058
Radar	rdar://81836061
Original Reporter	@ahoppen
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: b10f4fa893a89b7f7933142ba5f922ce

Issue Description:

Once #414 is merged we will have semantic tokens support in SourceKit-LSP.

It does, however, have two areas for improvement:

When SourceKit-LSP receives new semantic tokens from sourcekitd, it sends a WorkspaceSemanticTokensRefreshRequest, which causes the editor to update semantic tokens for all files and not just the current one. The request is intended for global changes like build config changes. We need to do this because before we receive semantic tokens, we serve the semantic tokens request by lexical tokens.
We currently eagerly parse all syntactic and semantic tokens into {{SyntaxHighlightingToken}}s, even if the client never requests semantic tokens

I think we could improve this by trying to only store the minimum amount of information to lazily construct {{SyntaxHighlightingToken}}s at first (e.g. just store the XPC responses or tokens in UTF-8 offset instead of converting them to UTF-16 up-front).

Once the client sends a DocumentSemanticTokensRequest, we will wait until the semantic tokens for the requested document have been computed and then compute the {{SyntaxHighlightingToken}}s.

This way we (a) reduce the amount of work that is done speculatively and (b) since we wait with the response to the DocumentSemanticTokensRequest until we actually have semantic tokens, we don’t need to send the WorkspaceSemanticTokensRefreshRequest anymore.

[SR-13738] sourcekit-lsp.exe crashes in Visual Studio Code on Windows


Previous ID	SR-13738
Radar	None
Original Reporter	Fritzt (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Attachment: Download

Environment

Windows 10

Visual Studio 2019

Visual Studio Code 1.50.1

Swift 20201015.1 CI VS2019

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug, Windows
Assignee	@compnerd
Priority	Medium

md5: 2b82a701b93d0e2c66a18837af159df7

Issue Description:

Having the SourceKit-LSP extension installed in Visual Studio Code, sourcekit-lsp.exe crashes while displaying a simple swift file. See attachment for crash backtrace.

[SR-15633] SourceKit-LSP: New files are not registered and changes to Package.swift are not reflected


Previous ID	SR-15633
Radar	None
Original Reporter	@adam-fowler
Type	Bug
Status	In Progress
Resolution

Environment

VSCode 1.6.3.2

swift-driver version: 1.26.21 Apple Swift version 5.5.2 (swiftlang-1300.0.47.5 clang-1300.0.29.30)

Target: x86_64-apple-macosx12.0

Additional Detail from JIRA


Votes	1
Component/s	SourceKit-LSP
Labels	Bug
Assignee	@ahoppen
Priority	Medium

md5: 3cdf5d87457acc541fc8aa99b1919384

is duplicated by:

SR-15679 SourceKit-LSP: Adding platform requirement in Package.swift is not propagated

Issue Description:

When a new file is created the SourceKit-LSP server doesn't seem to register it. You get basic function completion for standard swift objects, but none of the symbols in your project are available.

This was replicated in the new vscode plugin https://github.com/swift-server/vscode-swift but can also be replicated using the sample extension code that is part of the SourceKit-LSP project.

The current version of the vscode plugin does not send `workspace/didChangeWatchedFiles` events but I have a PR which does this swift-server/vscode-swift#98 For example new file will send

[Trace - 17:10:42] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "file:///Users/adamfowler/Developer/tools/sourcekit-lsp/Sources/SKCore/test.swift",
            "type": 1
        }
    ]
}

Even with sending these events I am not seeing this working. I can see the merged PR #376 which adds support for at least parsing these events, but from what I can see it doesn't actually process the add/remove event.

[SR-16104] SourceKit-LSP: Add support for RenameRequest


Previous ID	SR-16104
Radar	None
Original Reporter	@adam-fowler
Type	Improvement

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Improvement
Assignee	None
Priority	Medium

md5: 8028e8b5f474f8ce22efadde5bd6c30a

Issue Description:

Add support for RenameRequest message.

[SR-11164] indexstore-db is using the system Block.h instead of the dispatch-bundled one


Previous ID	SR-11164
Radar	None
Original Reporter	@kevints
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	@benlangmuir
Priority	Medium

md5: 5bfefb858f06706145adf59bed6e941b

Issue Description:

On a Linux system without a blocksruntime package installed, indexstore-db fails to build, despite pointing its include path to the installed headers. This is because the Block.h header is installed as /usr/lib/swift/Block/Block.h and it is including it as Block.h.

/code/swift-nightly-install/usr/bin/clang -target x86_64-unknown-linux --sysroot / -fPIC -O2 -DSWIFT_PACKAGE=1 -fblocks -fmodules -fmodule-name=IndexStoreDB_LLVMSupport -I /code/indexstore-db/lib/LLVMSupport/include -fmodules-cache-path=/code/build/buildbot_linux/indexstoredb-linux-x86_64/x86_64-unknown-linux/release/ModuleCache -I /code/swift-nightly-install/usr/lib/swift -MD -MT dependencies -MF /code/build/buildbot_linux/indexstoredb-linux-x86_64/x86_64-unknown-linux/release/IndexStoreDB_LLVMSupport.build/Support/circular_raw_ostream.cpp.d -std=c++11 -c /code/indexstore-db/lib/LLVMSupport/Support/circular_raw_ostream.cpp -o /code/build/buildbot_linux/indexstoredb-linux-x86_64/x86_64-unknown-linux/release/IndexStoreDB_LLVMSupport.build/Support/circular_raw_ostream.cpp.o
/code/indexstore-db/lib/Support/Concurrency-Mac.cpp:19:10: fatal error: 'Block.h' file not found
#include <Block.h>
         ^~~~~~~~~
1 error generated.

[SR-11309] Transport error: Input/output error after running sourcekit-lsp tests


Previous ID	SR-11309
Radar	None
Original Reporter	cukier (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Environment

Ubuntu 19.04

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: ff32cf13316732cf5a92467880feab5d

Issue Description:

after running

$/home/cukier/Developer/swift-DEVELOPMENT-SNAPSHOT-2019-06-29-a-ubuntu18.04/usr/bin/swift test -Xcxx -I/home/cukier/Developer/swift-DEVELOPMENT-SNAPSHOT-2019-06-29-a-ubuntu18.04/usr/lib/swift -Xcxx -I/home/cukier/Developer/swift-DEVELOPMENT-SNAPSHOT-2019-06-29-a-ubuntu18.04/usr/lib/swift/Block

i get

E[22:19:16.197] Transport error: Input/output error

printed multiple times, even after next command prompt is printed. @benlangmuir says that these come from clangd

Problem doesn't exist on macos

[SR-13653] SourceKit-LSP: show full type signature in autocompletion


Previous ID	SR-13653
Radar	rdar://problem/69958775
Original Reporter	@xAlien95
Type	Improvement

Attachment: Download

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Improvement
Assignee	None
Priority	Medium

md5: 082a2c11b6e53a2c078c70bdfa52294a

Issue Description:

Currently, when typing max you get

max(_ x: Comparable, _ y: Comparable) -> Comparable

as a suggested type signature, which may led the user into thinking that the function accepts existential protocol types instead of a unique type "T: Comparable" in both the arguments and result (see attached image, P1 and P2 are protocols, C1 is a class).

It may be more useful to show

max<T: Comparable>(_ x: T, _ y: T) -> T

as suggested type signature, although less readable.

We have the same issue when typing in the function body:

protocol SomeProtocol {}
class SomeClass {}

func foo<T: Collection>(_ x: T) {
    x  // suggested as "x: Collection" instead of "x: T"
}

func bar<T: SomeClass & SomeProtocol>(_ x: T) { 
    x // suggested as "x: SomeProtocol" instead of "x: T" 
}

[SR-15299] Compiler crash building sourcekit-lsp on Ubuntu 20.04 (LTS) x64


Previous ID	SR-15299
Radar	None
Original Reporter	dexterleng (JIRA User)
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	Compiler, SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: c02aa341aa43ce65bce8c2120fb90575

Issue Description:

I have verified that the dependencies listed (libsqlite3-dev, libncurses5-dev, python, ninja-build) are installed.

Swift Version:

dleng@dev:~/sourcekit-lsp$ swift -v
Swift version 5.5 (swift-5.5-RELEASE)

dleng@dev:~/sourcekit-lsp$ swift build -Xcxx -I${HOME}/swift/swift-5.5-RELEASE-ubuntu20.04/usr/lib/swift -Xcxx -I${HOME}/swift/swift-5.5-RELEASE-ubuntu20.04/usr/lib/swift/Block
swift-frontend: /home/build-user/swift/lib/IRGen/GenDecl.cpp:3988: llvm::Function *swift::irgen::IRGenModule::getAddrOfTypeMetadataAccessFunction(swift::CanType, swift::ForDefinition_t): Assertion `!type->hasArchetype() && !type->hasTypeParameter()' failed.
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace.
Stack dump:
0.  Program arguments: /home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend -frontend -c -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/API.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Model/CVE.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Model/Collection.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Model/License.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Model/Package.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Model/Search.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Model/TargetListResult.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/PackageCollections+CertificatePolicy.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/PackageCollections+Configuration.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/PackageCollections+Storage.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/PackageCollections+Validation.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/PackageCollections.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Providers/GitHubPackageMetadataProvider.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Providers/JSONPackageCollectionProvider.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Providers/PackageCollectionProvider.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Providers/PackageMetadataProvider.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Storage/FilePackageCollectionsSourcesStorage.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Storage/PackageCollectionsSourcesStorage.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Storage/PackageCollectionsStorage.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Storage/SQLitePackageCollectionsStorage.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Storage/Trie.swift -primary-file /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Utility.swift -supplementary-output-file-map /tmp/TemporaryDirectory.UyhMD8/supplementaryOutputs-1 -target x86_64-unknown-linux-gnu -disable-objc-interop -I /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug -color-diagnostics -enable-testing -g -module-cache-path /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/ModuleCache -swift-version 5 -Onone -D SWIFT_PACKAGE -D DEBUG -new-driver-path /home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-driver -resource-dir /home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/lib/swift -enable-anonymous-context-mangled-names -Xcc -fmodule-map-file=/home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollectionsSigningLibc/include/module.modulemap -Xcc -I -Xcc /home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollectionsSigningLibc/include -Xcc -fmodule-map-file=/home/dleng/sourcekit-lsp/.build/checkouts/swift-crypto/Sources/CCryptoBoringSSLShims/include/module.modulemap -Xcc -I -Xcc /home/dleng/sourcekit-lsp/.build/checkouts/swift-crypto/Sources/CCryptoBoringSSLShims/include -Xcc -fmodule-map-file=/home/dleng/sourcekit-lsp/.build/checkouts/swift-crypto/Sources/CCryptoBoringSSL/include/module.modulemap -Xcc -I -Xcc /home/dleng/sourcekit-lsp/.build/checkouts/swift-crypto/Sources/CCryptoBoringSSL/include -Xcc -fmodule-map-file=/home/dleng/sourcekit-lsp/.build/checkouts/swift-tools-support-core/Sources/TSCclibc/include/module.modulemap -Xcc -I -Xcc /home/dleng/sourcekit-lsp/.build/checkouts/swift-tools-support-core/Sources/TSCclibc/include -module-name PackageCollections -parse-as-library -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/API.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Model/CVE.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Model/Collection.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Model/License.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Model/Package.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Model/Search.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Model/TargetListResult.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/PackageCollections+CertificatePolicy.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/PackageCollections+Configuration.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/PackageCollections+Storage.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/PackageCollections+Validation.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/PackageCollections.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Providers/GitHubPackageMetadataProvider.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Providers/JSONPackageCollectionProvider.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Providers/PackageCollectionProvider.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Providers/PackageMetadataProvider.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Storage/FilePackageCollectionsSourcesStorage.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Storage/PackageCollectionsSourcesStorage.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Storage/PackageCollectionsStorage.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Storage/SQLitePackageCollectionsStorage.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Storage/Trie.swift.o -o /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/PackageCollections.build/Utility.swift.o -index-store-path /home/dleng/sourcekit-lsp/.build/x86_64-unknown-linux-gnu/debug/index/store -index-system-modules
1.  Swift version 5.5 (swift-5.5-RELEASE)
2.  
3.  While evaluating request IRGenRequest(IR Generation for file "/home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Storage/SQLitePackageCollectionsStorage.swift")
4.  While emitting IR SIL function "@$s18PackageCollections06SQLiteaB7StorageC13searchTargets11identifiers5query4type8callbackySayAA0aB5ModelO20CollectionIdentifierOGSg_SSAJ16TargetSearchTypeOys6ResultOyAJ0noQ0Vs5Error_pGctF05buildQ0L_yyFAJ0N8ListItemVAJ0N0V_SDy0aK00A8IdentityVShySaAaYRszlE0A7VersionVyAY_GGGtXEfU0_SaAaYRszlE0A0VyAY_GSgA2__A6_tXEfU_SbA5__A5_tcA5_mcfu_SbA5__A5_tcfu0_".
 for expression at [/home/dleng/sourcekit-lsp/.build/checkouts/swift-package-manager/Sources/PackageCollections/Storage/SQLitePackageCollectionsStorage.swift:519:62 - line:519:62] RangeText=""
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x5a1fd93]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x5a1dc7e]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x5a20115]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f948ee8d3c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f948e93418b]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f948e913859]
/lib/x86_64-linux-gnu/libc.so.6(+0x25729)[0x7f948e913729]
/lib/x86_64-linux-gnu/libc.so.6(+0x36f36)[0x7f948e924f36]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xa027ef]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x97e00c]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x97f27d]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x97e754]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x97e606]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xa93ec9]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xa944e7]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x97ba55]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xa93d1b]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xa902d7]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xb151eb]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xb13ca5]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xaf4252]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0xaf1aa4]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x9f5b0b]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x9281b6]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x951645]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x951599]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x935e1a]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x92b102]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x56c29a]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x56b588]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x55ed13]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x4b140e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f948e9150b3]
/home/dleng/swift/swift-5.5-RELEASE-ubuntu20.04/usr/bin/swift-frontend[0x4b104e]
[1/210] Compiling llvmSupport raw_ostream.cpp

[SR-12527] The `mutating` keyword is duplicated and displayed.


Previous ID	SR-12527
Radar	None
Original Reporter	MasasaM (JIRA User)
Type	Bug
Status	Resolved
Resolution	Duplicate

Attachment: Download

Environment

Apple Swift version 5.2 (swiftlang-1103.0.32.1 clang-1103.0.32.29)

Target: x86_64-apple-darwin19.3.0

Xcode 11.4

macOS 10.15.3

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: fba853f1e7c588eb749bf57265f82e5c

duplicates:

SR-12139 [Swift 5.2] 'mutating' printed twice in quick help

Issue Description:

Duplicate `mutating` keywords of your own functions.
There is a problem with SourceKit-LSP, which causes the same problem with non-Xcode editors. No problem with the standard library functions.

[SR-16106] Once SourceKit-LSP supports formatting, run formatter on text inserted by CodeActions


Previous ID	SR-16106
Radar	None
Original Reporter	@adam-fowler
Type	Bug

Environment

swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)

Target: x86_64-apple-macosx12.0

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 46482d3680d87dc38282b4865db4ef55

Issue Description:

The following list of Code Actions do not include the correct spacing

Generate Member Initializer
Expand Switch Cases
Collapse Nested If Statements
Move to Extension
Extract Expression
Extract Repeated Expression
Extract Method
Convert To Switch Statement

For example if I have the following struct

struct Test {
    let a: Int
}

The "Generate Member Initializer" code action produces

struct Test {
internal init(a: Int) {
self.a = a
}
    let a: Int
}

I haven't been able to test all the refactor kinds so there may be others that need fixed as well.

"Add Equatable Conformance" is an example of a code action that generates the correct spacing.

[SR-16095] SourceKit-LSP server expects a params parameter in the Shutdown request


Previous ID	SR-16095
Radar	rdar://91288093
Original Reporter	@adam-fowler
Type	Bug

Environment

Swift version 5.6 (swift-5.6-RELEASE)
Target: x86_64-unknown-linux-gnu

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: a65d66860c8ab33ed0fd6f1d62c95a20

Issue Description:

SourceKit-LSP server expects a params parameter in the Shutdown request when the spec says it shouldn't include any parameters.

Here is the request/response in the logs

[Trace - 10:19:45] Sending request 'shutdown - (20)'.[Trace - 10:19:45] Received response 'shutdown - (20)' in 2ms. Request failed: missing expected parameter: params (-32602).

This occurs on Linux but not on macOS.

[SR-9311] SourceKit-LSP should not use String.Index.encodedOffset as UTF16 offset


Previous ID	SR-9311
Radar	None
Original Reporter	@rintaro
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 8dfc9af638c0545d5e232c1909733399

Issue Description:

String.Index.encodedOffset doesn't necessarily mean UTF16 offset.

In Swift4.2 on macOS, '"こんにちは".endIndex.encodedOffset' results 5, but in the current master, it's 15 probably because apple/swift#20315 .

Moreover, if the string is backed by NSString it's 5 even in Swift5.

let str: String = "こんにちは"
print(str.endIndex.encodedOffset) // 15

import Foundation
let nsStr: NSString = "こんにちは"
let _nsStr = nsStr as String
print(_nsStr.endIndex.encodedOffset) // 5

[SR-10808] Implement textDocument/implementation request


Previous ID	SR-10808
Radar	None
Original Reporter	@benlangmuir
Type	New Feature
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	New Feature, StarterBug
Assignee	cukier (JIRA)
Priority	Medium

md5: 304466f6551cfc04ab251537228be24d

Issue Description:

Implement the textDocument/implementation request, which given a source location, resolves the symbol at that location, and returns the implementations of a given protocol, or protocol requirement.

https://microsoft.github.io/language-server-protocol/specification#textDocument_implementation

To implement this, you can start by looking at how jump to definition (textDocument/definition) resolves the symbol under the cursor, but instead of looking for its definition, look for all symbols that have a base relation with it (to find types that implement a protocol) or override relation (to find methods/properties that implement a protocol requirement). All of the database query methods to do this should already exist in indexstore-db's C++ code, although you may need to expose them in the Swift wrapper.

[SR-10807] Implement textDocument/typeDefinition request


Previous ID	SR-10807
Radar	None
Original Reporter	@benlangmuir
Type	New Feature

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	New Feature, StarterBug
Assignee	None
Priority	Medium

md5: 48898578051a40902ab5b8e1104d1a38

Issue Description:

Implement the textDocument/typeDefinition request, which given a source location finds the type of the symbol at that position and then returns the location of that type's definition.

https://microsoft.github.io/language-server-protocol/specification#textDocument_typeDefinition

To implement this, you can look at how the existing jump to defintiion request works (textDocument/definition), ~~but instead of using the key.usr field to get the declaration's USR, you can use the key.typeusr field.~~

Edit: it turns out typeusr is not suitable for this (https://forums.swift.org/t/usr-vs-typeusr-in-sourcekit/27759). It looks like to implement this we'll need to add a new field to sourcekitd's cursor_info. We want the USR of the type decl when that is available. For example,

var a =1 // a-> Int
var b = [1] // b -> Array
var c = (1, 2) // c -> nil
func test<T>(d: [T]) {} // d-> Array

So for a bound generic type like `Dictionary<Foo, Bar>`, we want to get the Dictionary decl's USR. When the type is non-nominal, such as a tuple or function type, we can just return null.

rdar://95597953

[SR-15875] SourceKit-LSP: Locally edited modules are ignored


Previous ID	SR-15875
Radar	rdar://89082936
Original Reporter	@adam-fowler
Type	Bug

Environment

swift-driver version: 1.26.21 Apple Swift version 5.5.2 (swiftlang-1300.0.47.5 clang-1300.0.29.30)

Target: x86_64-apple-macosx12.0

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 9855defbb99208c70a8c938d34e6f625

Issue Description:

If I locally edit a module from a package using `swift package edit` SourceKit-LSP ignores the local version and continues to use the original version of the module.

I know `swift package edit` is being deprecated, but there will be a replacement for it and it would be good if SourceKit-LSP worked for that. It may be worthwhile talking to SPM team to find out if the new solution will still use `workspace-state.json` to store module state.

[SR-13094] Sourcekit-lsp code completion is slow


Previous ID	SR-13094
Radar	None
Original Reporter	richardh (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	@benlangmuir
Priority	Medium

md5: c69b60f9e1d04c477f563a7317798b75

Issue Description:

We are seeing slow code completion performance using sourcekit-lsp and VS Code. Adding some log tracing around the various stages shows the following for 2 identical completion requests in the top level of a Swift file:

Step First request Second request
sourcekit request 1.38 0.35
JSON serialization 0.53 0.53
jsonrpc write 1.59 0.018

The response size was around 7MB.

[SR-12378] SKTests.testDependenciesUpdatedCXXTibs - Fatal error: error timedOut waiting for post-build diagnostics notification: file SourceKitTests.swift, line 284


Previous ID	SR-12378
Radar	rdar://95598365
Original Reporter	@benlangmuir
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: bbf17e241120bcbef3aa7759eeea981e

Issue Description:

https://ci.swift.org/job/swift-PR-Linux-smoke-test/20969

13:07:17 Test Case 'SKTests.testDependenciesUpdatedCXXTibs' started at 2020-03-17 20:07:17.947
13:07:18 I[20:07:18.038] clangd version 7.0.0 (https://github.com/apple/llvm-project.git f12bb53299b8732744cd61826ee38bcefd9597d6)
13:07:18 I[20:07:18.038] PID: 58040
13:07:18 I[20:07:18.038] Working directory: /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/buildbot_linux/sourcekitlsp-linux-x86_64/x86_64-unknown-linux-gnu/release/sk-tests/SKTests.testCodeCompleteSwiftTibs
13:07:18 I[20:07:18.038] argv[0]: /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/swift-nightly-install/usr/bin/clangd
13:07:18 I[20:07:18.038] argv[1]: -compile_args_from=lsp
13:07:18 I[20:07:18.038] argv[2]: -background-index=false
13:07:18 I[20:07:18.038] argv[3]: -index=false
13:07:18 I[20:07:18.038] Starting LSP over stdin/stdout
13:07:18 I[20:07:18.038] <-- initialize(1)
13:07:18 I[20:07:18.039] --> reply:initialize(1) 0 ms
13:07:18 I[20:07:18.041] <-- initialized
13:07:18 I[20:07:18.041] unhandled notification initialized
13:07:18 I[20:07:18.043] <-- workspace/didChangeConfiguration
13:07:18 I[20:07:18.043] <-- textDocument/didOpen
13:07:18 I[20:07:18.043] Updating file /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src/main.c with command 
13:07:18 [/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/build]
13:07:18 /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/swift-nightly-install/usr/bin/clang -fsyntax-only /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src/main.c -I . -I /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src -index-store-path index -index-ignore-system-symbols -fmodules -fmodules-cache-path=ModuleCache -o main-main.c.o -resource-dir=/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/swift-nightly-install/usr/lib/clang/7.0.0
13:07:18 I[20:07:18.044] <-- workspace/didChangeConfiguration
13:07:18 I[20:07:18.061] --> textDocument/publishDiagnostics
13:07:18 I[20:07:18.545] Updating file /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src/main.c with command 
13:07:18 [/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/build]
13:07:18 /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/swift-nightly-install/usr/bin/clang -fsyntax-only /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src/main.c -I . -I /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src -index-store-path index -index-ignore-system-symbols -fmodules -fmodules-cache-path=ModuleCache -o main-main.c.o -resource-dir=/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/swift-nightly-install/usr/lib/clang/7.0.0
13:07:18 I[20:07:18.561] --> textDocument/publishDiagnostics
13:07:18 I[20:07:18.601] <-- textDocument/didChange
13:07:19 I[20:07:19.102] Updating file /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src/main.c with command 
13:07:19 [/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/build]
13:07:19 /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/swift-nightly-install/usr/bin/clang -fsyntax-only /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src/main.c -I . -I /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src -index-store-path index -index-ignore-system-symbols -fmodules -fmodules-cache-path=ModuleCache -o main-main.c.o -resource-dir=/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/swift-nightly-install/usr/lib/clang/7.0.0
13:07:19 I[20:07:19.104] Skipping rebuild of the AST for /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/tmp/sk-test-data/SKTests.testDependenciesUpdatedCXXTibs/src/main.c, inputs are the same.
13:07:21 Fatal error: error timedOut waiting for post-build diagnostics notification: file /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/sourcekit-lsp/Tests/SourceKitTests/SourceKitTests.swift, line 284
13:07:21 E[20:07:21.768] Transport error: Input/output error
13:07:21 I[20:07:21.768] LSP finished, exiting with status 1
13:07:21 E[20:07:21.768] Transport error: Input/output error
13:07:21 I[20:07:21.768] LSP finished, exiting with status 1
13:07:21 E[20:07:21.768] Transport error: Input/output error
13:07:21 I[20:07:21.768] LSP finished, exiting with status 1
13:07:21 E[20:07:21.768] Transport error: Input/output error
13:07:21 I[20:07:21.768] LSP finished, exiting with status 1
13:07:21 E[20:07:21.768] Transport error: Input/output error
13:07:21 I[20:07:21.768] LSP finished, exiting with status 1
13:07:21 E[20:07:21.769] Transport error: Input/output error
13:07:21 I[20:07:21.769] LSP finished, exiting with status 1
13:07:21 E[20:07:21.770] Transport error: Input/output error
13:07:21 I[20:07:21.770] LSP finished, exiting with status 1
13:07:21 Exited with signal code 4

[SR-10806] Implement workspace/symbol request


Previous ID	SR-10806
Radar	None
Original Reporter	@benlangmuir
Type	New Feature
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	New Feature, StarterBug
Assignee	literalpie (JIRA)
Priority	Medium

md5: 88e6c20bbce2e4e811331802adca7a81

Issue Description:

Implement the workspace/symbol request, which given a query string returns all symbols that match.

https://microsoft.github.io/language-server-protocol/specification#workspace_symbol

To implement this, I suggest exposing the following methods from indexstore-db to the Swift wrapper code:

foreachSymbolName
foreachCanonicalSymbolOccurrenceByName

Then SourceKit-LSP can use the foreachSymbolName to get all the symbol names and perform matching against them, followed by foreachCanonicalSymbolOccurrenceByName to get the symbol information.

[SR-15918] Sourcekit-LSP reverts swift package edit


Previous ID	SR-15918
Radar	rdar://89551074
Original Reporter	@adam-fowler
Type	Bug

Environment

Apple Swift version 5.6-dev (LLVM 62b900d3d0d5be9, Swift ce64fe8867792d4)
vscode extension v0.3.0

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 09b4fc6b8bc8b6b62a4ce159b0ab11b5

Issue Description:

5.6 version of sourcekit-lsp reverts any attempt at local editing of packages. This was replicated using vscode extension.

Run vscode with 5.6 version of toolchain
Open project
Open .build/workspace-state.json
Right click on dependency and select 'Use Local Version' and select local version of a dependency
Watch workspace-state.json change to include edited state of dependency and then watch it revert back to non-edited almost immediately.

The revert does not occur if I stop the sourcekit-lsp server

[SR-14661] "Rename" operation creates bogus output for captured variable


Previous ID	SR-14661
Radar	rdar://problem/78522816
Original Reporter	jumhyn (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	@ahoppen
Priority	Medium

md5: c2dcdcb86e3f4499127f029ec85ded56

Issue Description:

Using Xcode's "Rename" tool for a captured variable produces nonsense output:

If we start with:

        let test = 0

        let closure = { [test] in
            print(test)
        }

and then use the "Rename" tool on the first `test` to rename to `test2`, we end up with the following output:

        let test2 = 0

        let closure = { [test2test2test2] in
            print(test2)
        }

Using "Rename" on the second occurrence is even worse:

        let ttttttettteesttttettteesesttttttettteesttttettteesestest2 = 0

        let closure = { [ttttttettteesttttettteesesttttttettteesttttettteesestest2ttttttettteesttttettteesesttttttettteesttttettteesestest2ttttttettteesttttettteesesttttttettteesttttettteesestest2] in
            print(ttttttettteesttttettteesesttttttettteesttttettteesestest2)
        }

(this is the result of re-typing the entirely of "test2", rather than just adding a "2")

"Rename" on the third occurrence of "test" produces the same outcome as the first

[SR-15664] SourceKit-LSP: New imports are not indexed


Previous ID	SR-15664
Radar	None
Original Reporter	@adam-fowler
Type	Bug
Status	Closed
Resolution	Cannot Reproduce

Environment

VSCode 1.6.3.2

swift-driver version: 1.26.21 Apple Swift version 5.5.2 (swiftlang-1300.0.47.5 clang-1300.0.29.30)

Target: x86_64-apple-macosx12.0

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 7460cbab9250931c0c1aa4ef303519ac

Issue Description:

If I add an import to a file the symbols from that import are not available

Add `import MyLib` to top of file
Start to type name of symbol from MyLib

I would expect to see the name of the symbol to appear but it doesn't.

This was replicated in the new vscode plugin https://github.com/swift-server/vscode-swift but can also be replicated using the sample extension code that is part of the SourceKit-LSP project.

[SR-11051] sourcekit-lsp tests failing on Linux with: toolchain is invalid: could not find the `swiftc` at expected path /usr/bin/usr/bin/swiftc


Previous ID	SR-11051
Radar	None
Original Reporter	cukier (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Environment

Ubuntu 19.04

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 19ca381d8eced20f3690720f329e62c5

Issue Description:

When I try to run tests on linux, everything explodes, makes me sad, and prevents me from writing my own tests. : ( If I add toolchain to my $PATH, then the expected path changes, but is still wrong

cukier@papryka:~/Developer/sourcekit-lsp$ git rev-parse HEAD
20662cd553ae4b769055d55c6ee49ae52a8824cb
cukier@papryka:~/Developer/sourcekit-lsp$ /home/cukier/Developer/swift-DEVELOPMENT-SNAPSHOT-2019-06-29-a-ubuntu18.04/usr/bin/swift test -Xcxx -I/home/cukier/Developer/swift-DEVELOPMENT-SNAPSHOT-2019-06-29-a-ubuntu18.04/usr/lib/swift -Xcxx -I/home/cukier/Developer/swift-DEVELOPMENT-SNAPSHOT-2019-06-29-a-ubuntu18.04/usr/lib/swift/Block
[34/34] Linking SourceKitLSPPackageTests.xctest
<lots of test cases here>
     Executed 10 tests, with 0 failures (0 unexpected) in 0.003 (0.003) seconds
Test Suite 'SwiftPMWorkspaceTests' started at 2019-06-30 20:35:17.517
Test Case 'SwiftPMWorkspaceTests.testBasicCXXArgs' started at 2019-06-30 20:35:17.517
Fatal error: 'try!' expression unexpectedly raised an error: toolchain is invalid: could not find the `swiftc` at expected path /usr/bin/usr/bin/swiftc: file /home/cukier/Developer/sourcekit-lsp/Tests/SKSwiftPMWorkspaceTests/SwiftPMWorkspaceTests.swift, line 319
Current stack trace:
0    libswiftCore.so                    0x00007f2e433aff00 swift_reportError + 50
1    libswiftCore.so                    0x00007f2e4341f1a0 _swift_stdlib_reportFatalErrorInFile + 115
2    libswiftCore.so                    0x00007f2e433496ee <unavailable> + 3626734
3    libswiftCore.so                    0x00007f2e43349867 <unavailable> + 3627111
4    libswiftCore.so                    0x00007f2e43124ccd <unavailable> + 1379533
5    libswiftCore.so                    0x00007f2e4331c728 <unavailable> + 3442472
6    libswiftCore.so                    0x00007f2e43148b55 <unavailable> + 1526613
7    SourceKitLSPPackageTests.xctest    0x0000561160998c80 <unavailable> + 6659200
8    SourceKitLSPPackageTests.xctest    0x000056116077aabc <unavailable> + 4438716
9    SourceKitLSPPackageTests.xctest    0x000056116099b771 <unavailable> + 6670193
10   libXCTest.so                       0x00007f2e422a5ec1 <unavailable> + 184001
11   libXCTest.so                       0x00007f2e422a5f1e <unavailable> + 184094
12   libXCTest.so                       0x00007f2e422a5e94 <unavailable> + 183956
13   libXCTest.so                       0x00007f2e42299977 <unavailable> + 133495
14   libXCTest.so                       0x00007f2e422a54b0 XCTestCase.invokeTest() + 73
15   libXCTest.so                       0x00007f2e422a5110 XCTestCase.perform(_:) + 172
16   libXCTest.so                       0x00007f2e422a8fe0 XCTest.run() + 191
17   libXCTest.so                       0x00007f2e422a6c40 XCTestSuite.perform(_:) + 232
18   libXCTest.so                       0x00007f2e422a8fe0 XCTest.run() + 191
19   libXCTest.so                       0x00007f2e422a6c40 XCTestSuite.perform(_:) + 232
20   libXCTest.so                       0x00007f2e422a8fe0 XCTest.run() + 191
21   libXCTest.so                       0x00007f2e422a6c40 XCTestSuite.perform(_:) + 256
22   libXCTest.so                       0x00007f2e422a8fe0 XCTest.run() + 191
23   libXCTest.so                       0x00007f2e422a3d20 XCTMain(_:) + 1091
24   SourceKitLSPPackageTests.xctest    0x0000561160ac215c <unavailable> + 7876956
25   libc.so.6                          0x00007f2e41d40a80 __libc_start_main + 235
26   SourceKitLSPPackageTests.xctest    0x00005611603dab3a <unavailable> + 637754
Exited with signal code 4

[SR-14980] Sourcekit-LSP crash after interrupting an incomplete completion


Previous ID	SR-14980
Radar	rdar://problem/81277873
Original Reporter	wibe (JIRA User)
Type	Bug
Status	Closed
Resolution	Invalid

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	wibe (JIRA)
Priority	Medium

md5: 4181e452d8e664e1f6b7f5ec72f3ff7e

Issue Description:

Expected Behaviour:
the server not to crash and return results.

Current Behaviour :
the server crashed and only empty results after that

Steps to reproduce:

install sourcekit-lsp: https://github.com/emacs-lsp/lsp-sourcekit on emacs
install the swift toolchain
open a swift file
type "fun", select the "func"- option from the dropdown
try typing out "hello(name: string)" ignoring any suggestion

Context:

os: osx, editor: emacs, toolchain: 5.4.2

Detailed description:
if done so as described above the sourcekit-lsp crashes
```
func hello(na
--------------^ here
```
it seems after the return message "request cancelled" with the code "-32800" the process sourcekit-lsp only provides empty responses. i included such an empty response in the following stacktrace, which starts from the point where I have selected the "func" option
and ends one message after the crash.

https://termbin.com/kwyw

the error from sourcekit-lsp:
2021-07-21 02:46:22.001 sourcekit-lsp[47:a15a5700] triggerFromIncompleteCompletions with incompatible completion session; expected DocumentURI(storage: \url{file:///work/cards/service/test/Sources/test/main.swift})@29, but got DocumentURI(storage: \url{file:///work/cards/service/test/Sources/test/main.swift})@35

[SR-12491] Create a branch of sourcekit-lsp setup with the latest released Swift toolchain


Previous ID	SR-12491
Radar	rdar://problem/62201105
Original Reporter	@benlangmuir
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 7be0189d3ec7cd413edbff041349f37e

Issue Description:

It would be useful to have a branch (e.g. master-with-swift-5.2) that contains the latest changes to sourcekit-lsp, but built to work with the currently released swift-5.2 toolchain. Currently we only have master (which works with master swift/swiftpm) and swift-5.2-branch (which works with swift-5.2, but does not receive new changes since it is already released).

Specifics

Create a branch master-with-swift-5.2 that uses master sourcekit-lsp, but swiftpm from 5.2.
Add PR testing for this branch that uses the latest released toolchain. This could be simpler than the existing PR testing and just use the downloadable toolchain instead of build swift from source.
Add a gated automerger from master to master-with-swift-5.2 if it tests successfully.
When we release swift-5.3, end support for 5.2 and move to master-with-5.3.

[SR-13145] Add '(' to the trigger characters for code completion


Previous ID	SR-13145
Radar	None
Original Reporter	srinikhil07 (JIRA User)
Type	Improvement

Attachment: Download

Additional Detail from JIRA


Votes	0
Component/s	CodeCompletion, SourceKit-LSP
Labels	Improvement
Assignee	None
Priority	Medium

md5: c766dd4b8f3f8aba0394fcdd22896d51

Issue Description:

Toolchain:

I am using sourcekit-lsp bundled in Xcode-12 beta 1 on macOS 10.15.5 and my editor is VSCode.

Improvement:

When I type the below in both Xcode and VSCode, I get different results.

 var array = Array(

For Xcode, I get the perfect code completion as shown below,

But the same in VSCode, I get empty result.

I am not sure if Xcode 12 uses sourcekit-lsp for code completion. But it would be awesome if we get same level of richness in VSCode as well.

I would love to contribute for this improvement.

[SR-11278] "could not open compilation database" if you xcode-select a beta


Previous ID	SR-11278
Radar	None
Original Reporter	cukier (JIRA User)
Type	Bug
Status	Resolved
Resolution	Cannot Reproduce

Environment

$SOURCEKIT_TOOLCHAIN_PATH/usr/bin/swift --version
Apple Swift version 5.1-dev (LLVM 200186e28b, Swift caeb2a44a8)
Target: x86_64-apple-darwin18.6.0

swift --version
Apple Swift version 5.1 (swiftlang-1100.0.257.2 clang-1100.0.31.3)
Target: x86_64-apple-darwin18.6.0

macos
10.14.5 (18F132)

Xcode
Version 11.0 beta 4 (11M374r)

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: bd6163e5c7459b50c9e805c13d0e2534

Issue Description:

If I have Xcode beta `xcode-select`ed, then my sourcekit-lsp breaks partially - requests like "find all references" and "go to implementation" don't work. sourcekit-lsp test suite crashes when running (force unwrap iirc)

When I open a swift package created with the beta Xcode:

[Trace - 9:53:18 AM] Sending request 'initialize - (0)'.
[Trace - 9:53:18 AM] Received notification 'window/logMessage'.
package at '/Users/dkiszkiel/Desktop/foo' is using Swift tools version 5.1.0 but the installed version is 5.0.0
[Trace - 9:53:18 AM] Received notification 'window/logMessage'.
failed to create SwiftPMWorkspace: the package does not contain a buildable target
[Trace - 9:53:18 AM] Received response 'initialize - (0)' in 143ms.
[Trace - 9:53:18 AM] Sending notification 'initialized'.
[Trace - 9:53:18 AM] Sending notification 'textDocument/didOpen'.
[Trace - 9:53:18 AM] Received notification 'window/logMessage'.
could not open compilation database for /Users/dkiszkiel/Desktop/foo/Sources/foo/main.swift
[Trace - 9:53:18 AM] Received notification 'window/logMessage'.
could not open compilation database for /Users/dkiszkiel/Desktop/foo/Sources/foo/main.swift

When I open swift package created with Xcode 10.2:

[Trace - 9:56:42 AM] Sending request 'initialize - (0)'.
[Trace - 9:56:42 AM] Received notification 'window/logMessage'.
manifest parse error(s):
/Users/dkiszkiel/Desktop/foo/Package.swift:6:15: error: 'init(name:pkgConfig:providers:products:dependencies:targets:swiftLanguageVersions:cLanguageStandard:cxxLanguageStandard:)' is unavailable
let package = Package(
              ^~~~~~~
PackageDescription.Package:27:12: note: 'init(name:pkgConfig:providers:products:dependencies:targets:swiftLanguageVersions:cLanguageStandard:cxxLanguageStandard:)' was introduced in PackageDescription 4.2
    public init(name: String, pkgConfig: String? = nil, providers: [PackageDescription.SystemPackageProvider]? = nil, products: [PackageDescription.Product] = [], dependencies: [PackageDescription.Package.Dependency] = [], targets: [PackageDescription.Target] = [], swiftLanguageVersions: [PackageDescription.SwiftVersion]? = nil, cLanguageStandard: PackageDescription.CLanguageStandard? = nil, cxxLanguageStandard: PackageDescription.CXXLanguageStandard? = nil)
           ^
/Users/dkiszkiel/Desktop/foo/Package.swift:15:10: error: 'target(name:dependencies:path:exclude:sources:publicHeadersPath:)' is unavailable
        .target(
         ^~~~~~
PackageDescription.Target:34:24: note: 'target(name:dependencies:path:exclude:sources:publicHeadersPath:)' was introduced in PackageDescription 4
    public static func target(name: String, dependencies: [PackageDescription.Target.Dependency] = [], path: String? = nil, exclude: [String] = [], sources: [String]? = nil, publicHeadersPath: String? = nil) -> PackageDescription.Target
                       ^
/Users/dkiszkiel/Desktop/foo/Package.swift:18:10: error: 'testTarget(name:dependencies:path:exclude:sources:)' is unavailable
        .testTarget(
         ^~~~~~~~~~
PackageDescription.Target:38:24: note: 'testTarget(name:dependencies:path:exclude:sources:)' was introduced in PackageDescription 4
    public static func testTarget(name: String, dependencies: [PackageDescription.Target.Dependency] = [], path: String? = nil, exclude: [String] = [], sources: [String]? = nil) -> PackageDescription.Target
                       ^
[Trace - 9:56:42 AM] Received notification 'window/logMessage'.
failed to create SwiftPMWorkspace: the package does not contain a buildable target
[Trace - 9:56:42 AM] Received response 'initialize - (0)' in 356ms.
[Trace - 9:56:42 AM] Sending notification 'initialized'.
[Trace - 9:56:42 AM] Sending notification 'textDocument/didOpen'.
[Trace - 9:56:42 AM] Received notification 'window/logMessage'.
could not open compilation database for /Users/dkiszkiel/Desktop/foo/Sources/foo/main.swift
[Trace - 9:56:42 AM] Sending request 'textDocument/documentSymbol - (1)'.
[Trace - 9:56:42 AM] Sending request 'textDocument/documentColor - (2)'.
[Trace - 9:56:42 AM] Received notification 'window/logMessage'.
could not open compilation database for /Users/dkiszkiel/Desktop/foo/Sources/foo/main.swift
[Trace - 9:56:42 AM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 9:56:42 AM] Received response 'textDocument/documentSymbol - (1)' in 18ms.
[Trace - 9:56:42 AM] Received response 'textDocument/documentColor - (2)' in 17ms.
[Trace - 9:56:42 AM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 9:56:42 AM] Sending request 'textDocument/foldingRange - (3)'.
[Trace - 9:56:42 AM] Received response 'textDocument/foldingRange - (3)' in 3ms.

Lsp

[SR-15278] Update struct definitions in SourceKit-LSP to LSP 3.16


Previous ID	SR-15278
Radar	rdar://83833293
Original Reporter	@ahoppen
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 01cd8296ea2d715b08d6ae20f66d0522

Issue Description:

I think the struct definitions in Sources/LanguateServerProtocol currently match version 3.14 of the LSP spec (established by #202 and #206 + whatever has been changed since.

To make sure, we are not missing any changes to the LSP spec, I think we should document which LSP version SourceKit-LSP currently implements. That way, when a new LSP version is published, we can go through the change log and update our definitions accordingly.

As part of this effort, I think we establish a well-defined state for our struct definitions again by updating them to LSP 3.16 (the current LSP spec).

[SR-16105] Generate Memberwise Initializer Code action has wrong position


Previous ID	SR-16105
Radar	None
Original Reporter	@adam-fowler
Type	Bug

Environment

swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)

Target: x86_64-apple-macosx12.0

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 558a0f6d14b233bd73627d164f9ba04d

Issue Description:

The SourceKit-lsp "Generate Memberwise Initializer" code action is positioned incorrectly. Instead of being positioned on the same line as the struct/class it is positioned one line above.

The same occurs for "Add Equatable Conformance"

[SR-12196] SourceKit inconsistently applies working directory to input files + non-file active document


Previous ID	SR-12196
Radar	rdar://problem/59400065
Original Reporter	Davidee (JIRA User)
Type	Bug

Environment

Confirmed with Xcode 11.2.1 - 11.4 beta 1

Additional Detail from JIRA


Votes	0
Component/s	Source Tooling, SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: cfa42aef639ca3e429020e9edf05098f

Issue Description:

If sourcekitd is passed a non-file URL, like `sourcekit-lsp` supports when using Visual Studio Code and source control integration (e.g. hg, git) but also passed a `-working-directory` for the compiler invocation, hypothetical arguments:

swiftc

...

'<my non file URL>'

-working-directory

'<my working directory>'

sourcekitd claims errors with:

'<my non file URL>' is not part of the input files even though it is part of the command line above.

I traced through a little bit of the SourceKit code and found that in resolveSymbolicLinksInInputs

all of the `input.file()` inputs have already been made absolute, including the given file, so SourceKit sees:

'<my working directory>/<my non file URL>' as an input, BUT it sees the primary file as '<my non file URL>', leading to the error seen above.

Potential fixes:

Make the input file matching more lenient
Standardize how the working directory is applied (seemingly earlier in the driver)
Try to detect these non-file URIs or teach SourceKit of a standard form which it can handle properly

[SR-13344] Lots of "Request Cancelled" logs when running sourcekit-lsp in VSCode


Previous ID	SR-13344
Radar	None
Original Reporter	@aciidb0mb3r
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 17ac4c1e8bef1ff1f89256aa4a646d77

Issue Description:

I see a lot of these messages when I edit any file in my Swift package in vscode:

error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled): 
error response (Request Cancelled):

[SR-11863] A few SourceKit assertions firing, testing with broad corpus of code


Previous ID	SR-11863
Radar	rdar://problem/57549295
Original Reporter	@johnno1962
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	@nathawes
Priority	Medium

md5: 6a29443091330df9d4086836fbe81b28

Issue Description:

Hi Apple,

I’ve been stress-testing sourcekit-lsp with a program that tokenises code then performs a cursor lookup on every entity that is an identifier or type identifier and running though the first 700 Swift Package projects in Dave Verwer’s manifest https://github.com/daveverwer/SwiftPMLibrary. The main problem so far as been assertions firing in SourceKit which are being tracked in the following “PR”: apple/swift#28051 along with how to replicate them by focusing on 17 particular packages. The most common crashes have been resolved already. Those that remain are in the attached zip file. The package reponsible can be seen in most of the crash reports.

[SR-9590] System modules not recognized by Sourcekit-LSP


Previous ID	SR-9590
Radar	None
Original Reporter	alexanderUV (JIRA User)
Type	Bug
Status	Closed
Resolution	Invalid

Environment

iMac 2017, running Mojave

swift toolchain: swift-5.0-DEVELOPMENT-SNAPSHOT-2018-12-28-a

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: f276496626aa47a16154374da56e7386

Issue Description:

I followed the instructions and got clangd in the PATH, but it doesn't seem to work.

Unless the instructions meant to use clangd independently for shim.h files? That can't be right.

In VSCode's output (from SourceKit-LSP) I can see:

could not open compilation database for /Users/alexander/dev/apple/project-sdl2/Sources/CSDL2/csdl2_umbrella.h

This is my shim file for a system module to SDL2

[SR-16080] SourceKit-LSP isn't aware of changes in other files


Previous ID	SR-16080
Radar	None
Original Reporter	@adam-fowler
Type	Bug

Environment

swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)

Visual Studio Code: 1.65.2

vscode-swift: 0.4.1

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 00ca6d48e63005108f7d259bffdb1d9a

Issue Description:

Changes in one file are not always registered by another.

Repro:

Create a new project
Open VSCode
Create a file and add a struct called Test
Create a second file and add a function using a struct called Test2
Go back to first file and rename Test to Test2 such that your code will compile
The "cannot find type 'Test2' in scope" error still displays
Compile the project (notice it compiles fine)
The "cannot find type 'Test2' in scope" error still displays.
The only way to fix this is to edit the second file and re-type Test2

Expected:

Changes that fix an error in another file should register as fixing that error

[SR-15877] SourceKit-LSP should support multiple workspace folders


Previous ID	SR-15877
Radar	rdar://89083082
Original Reporter	@ahoppen
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: ac795f76746bb6f9f4f821fc9bfd2e52

Issue Description:

Since version 3.6 LSP supports multiple workspace folders in the initialize request. SourceKit-LSP should support that option to open multiple Swift packages with a single SourceKit-LSP server instance.

[SR-13763] SourceKit-LSP should provide a better error when a "notification" is sent as a "request"


Previous ID	SR-13763
Radar	rdar://problem/70546466
Original Reporter	@benlangmuir
Type	Improvement

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Improvement
Assignee	None
Priority	Medium

md5: eeb6e0002ae127c14c5a2f79b3cf1187

Issue Description:

If a client incorrectly sends a notification message with a request id, we currently send the response "method not found: <method name>".

We should improve this error by checking if the method is a known notification so that it is clear what the issue is. E.g.

"<method name> is a notification message, but received as a request"

[SR-13561] SourceKit-LSP codecomplete.close/codecomplete.open ordering issues


Previous ID	SR-13561
Radar	rdar://problem/69101565
Original Reporter	Davidee (JIRA User)
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 626f287c88d5c1dd68fc1c1e65f382f1

Issue Description:

It's possible in some cases when SourceKit-LSP open and closes codecomplete sessions quickly that the close request is sent to sourcekitd before the open request finishes, leading to failures like:
codecomplete.close: no code completion session for <file>, <offset>

as well as causing failures with codecomplete.open at the same offset later on (since SourceKit-LSP thinks it hasn't opened anything but it has).

See

sourcekit-lsp/Sources/SourceKitLSP/Swift/CodeCompletionSession.swift

Line 212 in eaea937

queue.async {

,) with the current approach we'd need to wait on the Dispatch Group.

[SR-12447] sourcekit-lsp - libcurl.so.4: cannot open shared object file


Previous ID	SR-12447
Radar	rdar://problem/62201031
Original Reporter	rexmas (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Environment

Ubuntu 18.04

Swift 5.2

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	rexmas (JIRA)
Priority	Medium

Watchers: @shahmishal

md5: 51b1146c396991a04ed9c7f27d1ef570

Issue Description:

Running from Ubuntu 18.04

$ sourcekit-lsp 
sourcekit-lsp: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory

Looks like the following fixed it however

sudo apt-get update
sudo apt-get install libcurl4-openssl-dev

Possible update to the documentation?

[SR-15743] SourceKit-LSP isn't aware of changes in other modules


Previous ID	SR-15743
Radar	None
Original Reporter	svanimpe (JIRA User)
Type	Bug

Environment

Swift 5.5.2

vscode-swift pluging 0.1.1 in Visual Studio Code

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 05438341298387bc1e6d7b56e761d580

Issue Description:

I'm working on a Swift Package that contains both a library and an executable that uses said library. Whenever I make a change to the API of the library (such as changing the access level of a function from internal to public, or renaming arguments, ...), SourceKit-LSP doesn't pick up this change and reports compilation errors in the executable, even though it builds and runs fine.

These errors usually persist until I restart VS Code, although I have occasionally seen them resolve themselves.

CC @adam-fowler

[SR-12735] sourcekit-lsp doesn't handle headings correctly in hover response


Previous ID	SR-12735
Radar	rdar://problem/62895105
Original Reporter	cukier (JIRA User)
Type	Bug

Attachment: Download

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 2aca529ac78bd7e234ac3341b255ac12

Issue Description:

If you have a function with doc comment that includes headings, they are rendered with literal <h1> tags around them, instead of being bigger and boldier.

I did some debugging, and it seems that sourcekit returns headings as `<rawHTML><![CDATA[<h1>]]></rawHTML>two<rawHTML><![CDATA[</h1>]]></rawHTML>` instead of `<h1>two</h1>` that sourcekit-lsp expects

(sorry for the weird font, line 10 contains three equals characters "===")

![](Screen Shot 2020-05-05 at 3.24.26 PM.png)

[SR-15679] SourceKit-LSP: Adding platform requirement in Package.swift is not propagated


Previous ID	SR-15679
Radar	rdar://91230538
Original Reporter	@adam-fowler
Type	Bug
Status	Reopened
Resolution

Environment

swift-driver version: 1.26.21 Apple Swift version 5.5.2 (swiftlang-1300.0.47.5 clang-1300.0.29.30)

Target: x86_64-apple-macosx12.0

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 89724567877c11a1c46009ed4a119296

duplicates:

SR-15633 SourceKit-LSP: New files are not registered and changes to Package.swift are not reflected

Issue Description:

If I add an asynchronous function to a package SourceKit-LSP complains that concurrency is only available in macOS 10.15 or newer as it should. If I then go to my Package.swift and add a platform requirement eg

platforms: [.macOS(.v10_15)],

SourceKit-LSP stills continues to display the error, until I restart the sourcekit-lsp server.

Platform requirements in the Package.swift should be propagated as soon as the Package.swift is saved, not after restarting the server.

[SR-9296] Sourcekit crash with sourcekit-lsp jump to definition in test case


Previous ID	SR-9296
Radar	None
Original Reporter	@keith
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

swift-DEVELOPMENT-SNAPSHOT-2018-11-01-a.xctoolchain
sourcekit-lsp d0803e9

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 76c41e80b66aaa560c5c5a51d1980024

Issue Description:

With this code:

import XCTest

func execute(arguments: [String]) throws -> [String: Any]? {
    return nil
}

final class Tests: XCTestCase {
    func testSomething() throws {
        _ = try execute(arguments: []) as? [String: [String]]
    }
}

If you try to jump to the definition of `execute`, sourcekit crashes. Attached is a repro project and crash log.

[SR-14300] Documentation comment being parsed incorrectly.


Previous ID	SR-14300
Radar	None
Original Reporter	ccdoky (JIRA User)
Type	Bug
Status	Resolved
Resolution	Invalid

Attachment: Download

Environment

macOS: 11.2.1

xcode: 12.4(12D4e)

swift: Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP, SwiftSyntax
Labels	Bug
Assignee	None
Priority	Medium

md5: 584ffe581d5e132234624ebd7b6b4ebe

Issue Description:

If you write a document like: 

/** 
./folder/*
*/ 

Xcode will throw an error：Unterminated '/*' comment

class Test {
    /**
     Run lizard code cyclomatic complexity analysis.


     - parameters:
       - exclude: Exclude files that match this pattern. * matches everything, ? matches any single character, "./folder/*" exclude everything in the folder recursively. Multiple patterns can be specified. Don't forget to add "" around the pattern
     It counts 1)the nloc (lines of code without comments), 2)CCN (cyclomatic complexity number), 3)token count of functions. 4)parameter count of functions.
    */
    public func lizard(sourceFolder: String? = nil,
                       language: String = "swift",
                       exportType: String? = nil,
                       ccn: Any? = nil,
                       length: Any? = nil,
                       executable: String? = nil) {
    }
}

[SR-11356] TibsBuildTests.testBuildMixedLang failed XCTAssertEqual failed: ("[]") is not equal to ("["/home/buildnode...


Previous ID	SR-11356
Radar	None
Original Reporter	@aschwaighofer
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	@benlangmuir
Priority	Medium

md5: 077ae5e7ce9affa42895602492165a60

Issue Description:

https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/10103/consoleText

Test Suite 'TibsBuildTests' started at 2019-08-22 20:41:28.554
Test Case 'TibsBuildTests.testBuildMixedLang' started at 2019-08-22 20:41:28.554
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/indexstore-db/Tests/ISDBTibsTests/TibsBuildTests.swift:117: error: TibsBuildTests.testBuildMixedLang : XCTAssertEqual failed: ("[]") is not equal to ("["/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/tmp/TibsBuildTests.testBuildMixedLang/src/e.mm", "/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/tmp/TibsBuildTests.testBuildMixedLang/src/d.cpp"]") -
Test Case 'TibsBuildTests.testBuildMixedLang' failed (0.556 seconds)

[SR-13762] SourceKit-LSP textDocument/* requests return no results if document is not open


Previous ID	SR-13762
Radar	rdar://problem/70546468
Original Reporter	@benlangmuir
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 90305bde26b3949654dd517a12e74963

Issue Description:

The "textDocument/*" requests such as completion, definition, references, documentSymbol, etc. will return a fallback value (e.g. [] for completion, nil for documentSymbol) when they are called on a document that has not been opened.

We should improve these to either return an error indicating what went wrong, or else support it by opening the file from disk.

[SR-15016] sourcekit-lsp doesn't compile on macos


Previous ID	SR-15016
Radar	rdar://problem/81465580
Original Reporter	cukier (JIRA User)
Type	Bug
Status	Closed
Resolution	Cannot Reproduce

Additional Detail from JIRA


Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 61f164f3302199a312d7bb17defe47a4

Issue Description:

it fails in a different way than https://bugs.swift.org/browse/SR-14615

macos 11.4 (20F71)

swift-driver version: 1.26 Apple Swift version 5.5 (swiftlang-1300.0.19.104 clang-1300.0.18.4)
Target: x86_64-apple-macosx11.0

current main branch, commit 0d19d7d

$swift build
Updating https://github.com/apple/indexstore-db.git
Updated https://github.com/apple/indexstore-db.git (0.44s)
Updating https://github.com/apple/swift-package-manager.git
Updated https://github.com/apple/swift-package-manager.git (0.75s)
Updating https://github.com/apple/swift-tools-support-core.git
Updated https://github.com/apple/swift-tools-support-core.git (0.44s)
Updating https://github.com/apple/swift-llbuild.git
Updated https://github.com/apple/swift-llbuild.git (0.57s)
Updating https://github.com/apple/swift-driver.git
Updated https://github.com/apple/swift-driver.git (0.45s)
Updating https://github.com/jpsim/Yams.git
Updating https://github.com/apple/swift-argument-parser.git
error: Dependencies could not be resolved because root depends on 'swift-argument-parser' 0.4.1..<0.5.0 and root depends on 'swift-argument-parser' 0.3.1..<0.4.0.

Add missing protocol requirements placeholders not replaced

The add missing protocol requirements placeholders are not replaced with LSP snippets. The output is as follows

func missingRequirement() {
    <#code#>
}

Original bug came from vscode-swift extension swift-server/vscode-swift#269
I believe there is already a radar for this, but wanted to add an issue here so it can be tracked externally.

Swift version: swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
Target: x86_64-apple-macosx12.0

apple / sourcekit-lsp Goto Github PK

sourcekit-lsp's Introduction

SourceKit-LSP

Getting Started

Development

Indexing While Building

Status

Caveats

sourcekit-lsp's People

Contributors

Stargazers

Watchers

Forkers

sourcekit-lsp's Issues

Recommend Projects

Recommend Topics

Recommend Org