Skip to content

Go to Definition fails for properties using external package property wrappers #2758

Open
Open
Go to Definition fails for properties using external package property wrappers#2758

Description

@rssole
rssole
opened on Aug 27, 2026

Description

Go to Definition fails for properties using a property wrapper from an external Swift package

Editor

VS Code / Cursor using the official Swift extension and SourceKit-LSP

Description

Go to Definition does not work for a property when the property uses a property wrapper whose type comes from an external Swift package/module.

Navigation works normally for plain properties.

Navigation also works with SDK-provided property wrappers such as @Published.

However, when a property wrapper comes from an external Swift package:

  1. Go to Definition on the property wrapper type itself does not work.
  2. Go to Definition on the wrapped property also does not work.
  3. Removing the property wrapper immediately restores Go to Definition for the property.

The project builds successfully and navigation between other types/files/modules works correctly.

Likewise, replacing the external wrapper with an SDK-provided wrapper such as @Published allows navigation to work as expected.

Steps to reproduce

Example

Assume ExternalWrapper is defined in a Swift package dependency:

import ExternalPackage

final class Example {
    @ExternalWrapper
    var value: String

    func foo() {
        print(value)
        // Go to Definition on `value` does nothing.
    }
}

Go to Definition on:

ExternalWrapper

also does not navigate to the wrapper definition.

If the wrapper is removed:

final class Example {
    var value: String

    func foo() {
        print(value)
        // Go to Definition now correctly jumps to the property declaration.
    }
}

Expected behavior

Expected behavior

Go to Definition on value should navigate to:

@ExternalWrapper
var value: String

and Go to Definition on ExternalWrapper should navigate to its definition/source when the dependency source is available.

Actual behavior

Neither the external property wrapper type nor the wrapped property can be navigated to.

Removing the property wrapper makes navigation to the property work immediately.

Additional information

The package and application build successfully.

SourceKit-LSP otherwise has working cross-file and cross-module navigation in the same workspace.

This appears specific to property wrappers imported from external package/module dependencies rather than property wrappers in general.

Extension version

2.16.7

Swift & OS version

Swift version

Apple Swift 6.3.3

Platform

macOS / iOS Simulator

Update and more info

The issue is actually happening (seems so) when a property-wrapper-backed property property type is inferred from the wrapper initializer.

struct Dependencies {
    var service: ServiceProtocol
}

@propertyWrapper
struct Injected<Value> {
    init(_ keyPath: KeyPath<Dependencies, Value>) {
        // ...
    }

    var wrappedValue: Value {
        fatalError()
    }
}

final class Example {
    @Injected(\.service)
    private var service

    func foo() {
        service.doSomething()
        // Go to Definition on `service` fails
    }
}

but this works:

@Injected(\.service)
private var service: ServiceProtocol

Activity

  1. github-project-automation
    added this to Swift Extension for Visual Studio Codeon Aug 27, 2026
  2. github-project-automation
    moved this to Unscreened in Swift Extension for Visual Studio Codeon Aug 27, 2026

  3. matthewbastien commented on Aug 31, 2026

    @matthewbastien
    matthewbastien
    on Aug 31, 2026
    Member

    Thank you for the bug report!

    It seems like this is a SourceKit-LSP issue rather than a Swift extension issue. I'm going to transfer this over to the SourceKit-LSP repository for the maintainers there to have a look.

  4. matthewbastien
    transferred this issue fromswiftlang/vscode-swifton Aug 31, 2026
  5. matthewbastien
    removed this from Swift Extension for Visual Studio Codeon Aug 31, 2026

  6. ahoppen commented on Sep 1, 2026

    @ahoppen
    ahoppen
    on Sep 1, 2026
    Member

    Thanks for the report, @rssole. I was, however, unable to reproduce it. Would you be able to gather a diagnose bundle as described in https://github.com/swiftlang/sourcekit-lsp/blob/main/Documentation/Diagnose%20Bundle.md, ideally with extended logging enabled, and, if possible, a project that reproduces the issue. That would be great to determine what’s going wrong here.

  7. rssole commented on Sep 1, 2026

    @rssole
    rssole
    on Sep 1, 2026
    Author

    Thanks for the report, @rssole. I was, however, unable to reproduce it. Would you be able to gather a diagnose bundle as described in https://github.com/swiftlang/sourcekit-lsp/blob/main/Documentation/Diagnose%20Bundle.md, ideally with extended logging enabled, and, if possible, a project that reproduces the issue. That would be great to determine what’s going wrong here.

    Hey, well, thanks for looking into this, actually after lengthy discussion with Codex 😄 I have reached setup (via lsp server arguments) where source kit discovers and indexes everything required so all works like a charm....

    Essentially it was my lack of knowledge how sourcekit lsp works under the hood and how to setup and what arguments to give to SKLSP server....

    Feel free to close this thing 😄

  8. ahoppen commented on Sep 2, 2026

    @ahoppen
    ahoppen
    on Sep 2, 2026
    Member

    Out of curiosity: What was the change that fixed it? Knowing it might help others if they are facing a similar problem.

  9. ahoppen
    closed this as completedon Sep 2, 2026

  10. rssole commented on Sep 10, 2026

    @rssole
    rssole
    on Sep 10, 2026
    Author

    Out of curiosity: What was the change that fixed it? Knowing it might help others if they are facing a similar problem.

    Oh well sorry I didn't get there is this question 😄 ...to be honest I didn't dwell into all details what codex suggested but I believe this was key part:

    "-Xswiftc", "-I",
    "-Xswiftc", "/path/to/local/SPM/module/.build/arm64-apple-ios-simulator/debug/Modules",

    where build output was explicitly given to the lsp server... somehow perhaps due to complexity of my workspace lsp server didnt scan all that scanned should be.... I hope that will help anyone having issues with indexing/navigation.

  11. ahoppen commented on Sep 14, 2026

    @ahoppen
    ahoppen
    on Sep 14, 2026
    Member

    That should really not be necessary and we should figure out what needs to be done to support this out of the box. If you could attach the diagnose bundle (and possibly a project) as requested in #2758 (comment) that would be great.

    Also, could you share which command you use to build the package? Is it a plain swift build or do you add more arguments there as well?

  12. ahoppen
    reopened this on Sep 14, 2026

  13. rssole commented on Sep 14, 2026

    @rssole
    rssole
    on Sep 14, 2026
    Author

    oh well... it is really complicated stuff the project I am working on.... it is corporate thing and ridiculously complex....so not sure I could share it really....

    Yes it builds with swift build and packages resolution is fine.... yet it builds only with constraining it to iOS SDK because package which is part of workspace does not build for MacOS at all because of diverged mac os versions requirements among referenced packages. The thing is that all of that I did to make it work completely in Cursor as it XCode all works like a charm, so I was sure it can also work in Cursor, and after adding those inclusions and putting .build output directory within SPM package/component of workspace... LSP caught up...

  14. ahoppen commented on Sep 14, 2026

    @ahoppen
    ahoppen
    on Sep 14, 2026
    Member

    Could you share the swift build command you use to build your package? That should give me some more context of what might be the issue here.

  15. rssole commented on Sep 14, 2026

    @rssole
    rssole
    on Sep 14, 2026
    Author

    Yes of course... I give it sdk and tripple:

    swift build --sdk /Applications/Xcode-26.6.0.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator26.5.sdk --build-tests --triple arm64-apple-ios26.1-simulator

    without that, package won't compile (it is package and its dependencies fault not LSPs)

  16. ahoppen commented on Sep 14, 2026

    @ahoppen
    ahoppen
    on Sep 14, 2026
    Member

    Ah, in that case you should be able to get this to work with the following .sourcekit-lsp/config.json file that matches your build command.

    { 
  "swiftPM": {
    "sdk": "/Applications/Xcode-26.6.0.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator26.5.sdk"
    "triple": "arm64-apple-ios26.1-simulator"
  }
}

  17. rssole commented on Sep 14, 2026

    @rssole
    rssole
    on Sep 14, 2026
    Author

    Ah, in that case you should be able to get this to work with the following .sourcekit-lsp/config.json file that matches your build command.

    {
    "swiftPM": {
    "sdk": "/Applications/Xcode-26.6.0.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator26.5.sdk"
    "triple": "arm64-apple-ios26.1-simulator"
    }
    }

    Yes, I do have that, but even so, it wasn't indexing all the SPM modules and externally referenced packages and didn't go to definition present there. So ... intra-module it worked,but yet after adding those -i inclusions, it started working cross-module/packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions