add go-to-definition for inlay hints (#2318) by loveucifer · Pull Request #2436 · swiftlang/sourcekit-lsp

loveucifer · 2026-01-06T14:15:52Z

Implements resolveProvider for inlay hints to enable navigating to type definitions. When an inlay hint showing a type is resolved, the server looks up the type's definition location using cursorInfo and the index.

store variable position in InlayHint.data for resolution
add inlayHintResolve to LanguageService protocol
implement resolve handler using cursorInfo and index lookup
enable resolveProvider: true in capabilities
add test for resolve functionality

Addresses #2318

Implements resolveProvider for inlay hints to enable navigating to type definitions. When an inlay hint showing a type is resolved, the server looks up the type's definition location using cursorInfo and the index. - store variable position in InlayHint.data for resolution - add inlayHintResolve to LanguageService protocol - implement resolve handler using cursorInfo and index lookup - enable resolveProvider: true in capabilities - add test for resolve functionality Addresses swiftlang#2318

ahoppen · 2026-01-06T15:03:11Z

+      XCTAssertEqual(parts.count, 1)
+      XCTAssertNotNil(parts.first?.location, "Expected label part to have location for go-to-definition")
+    } else if case .string = resolvedHint.label {
+


I think the test only passes because we get into this case because there are no parts. AFAIK the problem is that the typeUSR field in the cursor info request isn’t actually a valid USR (looks like it hasn’t been used in a while). Furthermore, a purely USR-based implementation won’t be able to through the fallback locations in indexBasedDefinition and definitionLocations. In particular, it won’t be able to jump to a generated interface or jump to a definition if background indexing is disabled.

I think the correct implementation would be to extend the cursorinfo request to return line, column, filepath, module name and USR of the declaration’s type (maybe I forgot something else as well). The place to start debugging in order to do this would likely be https://github.com/swiftlang/swift/blob/f4e78a61dfbbaae7f1f03861d7ea8077546a4146/tools/SourceKit/tools/sourcekitd/lib/Service/Requests.cpp#L2736

The good news is that #548 would fall out for (almost) free and you would be able to fix the oldest open issue in this repo 😉

hmm seems like im having a hard time figuring out how to go forward with this ( does this require me to work within the compiler i mean swift/swiftlang and handle edgecases and tests for those as well because thats gotta be long ig )

if not ,i spent yesterday looking up fixes and found one ( idk if it works or has any more edgecases ) we could look up the type by its name string (e.g., "MyType") instead of the broken USR; it handles most casesig and would get this feature working immediately without me having to go through the compiler repo , that might take this pr a while , i mean i can do it but it will just take time maybe 2-4 days ig atleast to get fmailiar with the repo

does this require me to work within the compiler i mean swift/swiftlang

Yes, the entry barrier is definitely a little higher there but if you’re in for a challenge, I think you’d be up for it. If you get stuck somewhere, also feel free to just open a PR with how far you got and we can help you go on. I’d prefer to proper compiler-backed solution over something hacky in SourceKit-LSP because it will likely be a lot more error-resistant and easier to maintain.

Okey , i will try to learn the repo for a few days and try to fix the issue , should i convert this to a draft PR in the meantime

Haha, yes at some point you will need to know about sourcekitd when contributing to SourceKit-LSP. It’s where most of the actual semantic understanding meat is implemented. And because it’s a little harder to set up, those are the issues that don’t get tackled as quickly 😉

will try and do my best :)

loveucifer · 2026-01-08T15:27:29Z

new commit requires swiftlang/swift#86381 for compiler changes

update inlay hint resolution to use the new type declaration location fields from cursorInfo, with fallback to index lookup using the new typeDeclUsr (a proper declaration USR). Changes i made : - Regenerated sourcekitd_uids.swift with new keys - InlayHintResolve.swift: Try direct location first, fallback to index - InlayHintTests.swift: Fixed test to properly verify location This Requires: swift/swiftlang PR## #86381 for compiler changes

Add support for the textDocument/typeDefinition LSP request, which finds the type of the symbol at a given position and returns the location of that type's definition. This uses the same type definition lookup mechanism as the inlay hint resolution feature, which queries cursorInfo for the new type declaration location fields (typeDeclFilePath/Line/Column) with fallback to index lookup using typeDeclUsr. Fixes swiftlang#548

ahoppen · 2026-01-08T19:35:58Z

Very nice, I was expecting you to take longer to create a sourcekitd PR, good job 🌟

Let’s wait for swiftlang/swift#86381 to be approved and then I’ll review this PR in detail. Looked good from a first glance.

loveucifer · 2026-01-08T20:25:57Z

Very nice, I was expecting you to take longer to create a sourcekitd PR, good job 🌟

yess i thought so too but i did have some previous experience with c++ while wriitng my game engine and I spent some time yesterday and today reading through the repo and thought might as well do it and learn more as i go on :D , thanks for your kind wordsss ❤️

loveucifer · 2026-01-09T17:47:47Z

following the discussion in swiftlang/swift#86381. with hamishknight , ultimately reached the conclusion that we dont want any compiler changes , i am sending a pr that oughtta fix this but if not back to the compiler repo again we go :D

loveucifer · 2026-01-09T18:21:16Z

as mentinoed above, i discovered that no changes are needed in the Swift repo. The existing cursorInfo already supports looking up types by USR via key.usr.
one of the key insight was that key.typeusr returned by cursorInfo is a mangled type name (e.g., $sSiD for Int), not a declaration USR. to use it for index lookup or cursorInfo queries
so :
replacing $s prefix with s: (e.g., $sSi → s:Si)
Strip trailing [D]suffix (type descriptor marker)
This converts the mangled type to a proper declaration USR that works with:

Index lookups via primaryDefinitionOrDeclarationOccurrence(ofUSR:)
cursorInfo queries via key.usr parameter
Implementation:

added convertMangledTypeToUSR() helper for the conversion
lookupTypeDefinitionLocation() tries index lookup first (fast path), falls back to cursorInfo for types not in index
should ideally work for both local project types and SDK/external types

also i closed the Swift repo PR #86381 as it's no longer needed.

ahoppen

Uhh, very nice that we can do this without modifying the cursor info request. I know about the USR-based cursor info but totally forgot about it again. I hope you still learned something worthwhile setting up you compiler development environment 😉

ahoppen · 2026-01-09T21:47:50Z

-
-    # Used exclusively within the SourceKit Plugin
-    KIND('DiagRemark', 'source.diagnostic.severity.remark'),
+    # Note: DiagRemark was moved to UID_KINDS in UIDs.py


I don’t think this comment is providing any value. Let’s just remove it.

ahoppen · 2026-01-09T21:48:42Z

  func definition(_ request: DefinitionRequest) async throws -> LocationsOrLocationLinksResponse?

  func declaration(_ request: DeclarationRequest) async throws -> LocationsOrLocationLinksResponse?
+  func typeDefinition(_ request: TypeDefinitionRequest) async throws -> LocationsOrLocationLinksResponse?


I think typeDefinition doesn’t have any tests at the moment yet. I would suggest we move its implementation to a follow-up PR and focus this one on the inlay hints.

ahoppen · 2026-01-09T21:49:02Z

  }

+  func inlayHintResolve(_ req: InlayHintResolveRequest) async throws -> InlayHint {
+    // default: return hint unchanged


I don’t think this comment provides much value, so I’d just remove it.

ahoppen · 2026-01-09T21:51:53Z

+    // inlay hints store the uri in data for resolution
+    // extract uri from the lspany dictionary


Similar comment on the comment here. This exactly explains what’s being done below, so I don’t think it provides much value. In general, I’m a fan of comments that describe why something is done, not what is being done.

- Use cursorInfo USR lookup instead of index (more accurate) - Add document version tracking to reject stale resolve requests - Make InlayHintResolveData conform to LSPAnyCodable - Reference swiftlang/swift#86432 for mangled type workaround - cursorInfoFromTypeUSR takes DocumentSnapshot for version safety - Remove TypeDefinition.swift (defer to follow-up PR) - Remove unnecessary comments - Tests work without index

loveucifer · 2026-01-10T02:09:59Z

I hope you still learned something worthwhile setting up you compiler development environment 😉

Yess totally and i bet it will come of use while fixing other issues ,i have noticed that some of the issues needs me to work within it so its good .

hamishknight · 2026-01-10T16:49:25Z

+    // Strip trailing 'D' (type mangling suffix) to get declaration USR
+    if result.hasSuffix("D") {
+      result = String(result.dropLast())
+    }


You shouldn't need to do this, cursor info should be able to handle a type USR with it

Hmm but the tests fail without the D stripping.

Oh interesting, I saw handling of Demangle::Node::Kind::Type in the code and assumed that was referring to D but it's actually a different kind. I guess this is okay for now but we really ought to fix this on the sourcekitd side, ideally at the same time as the $s -> s: change.

Just to add my 2cts, while I’m not a huge fan, I’m fine with having the stripping of D as a temporary workaround for now as long as we try to adjust sourcekitd to work without this hack in the future.

ahoppen

Left a few more comments inline. I think the best way forward might be:

Remove all remainders of the type definition request from this PR
Get this merged
Support jumping to a generated interface from inlay hints. I suspect that this might require some careful re-shuffling of code which might be easier to review if done on its own without having to worry the changes that are currently part of this PR. And this PR already provides great value on its own

Also, just want to express how extremely excited I am to use the type definition request once it gets in. I keep wanting that multiple times a week 🙂

loveucifer · 2026-01-11T11:18:55Z

there is already a follow up PR in #2445 , should i include things that i left out here on that pr or work on an entirely new one ?

ahoppen · 2026-01-11T21:51:41Z

there is already a follow up PR in #2445 , should i include things that i left out here on that pr or work on an entirely new one ?

I just noticed that we eg. still have typeDefinition in LangaugeService. I’d pull that out of this PR and only add it in #2445, same for typeDefinitionProvider: .bool(true), not sure if there’s anything else.

ahoppen

Good to go, let’s just remove all references to typeDefinition from the diff.

ahoppen · 2026-01-12T07:52:54Z

@swift-ci Please test

ahoppen · 2026-01-12T07:58:49Z

@swift-ci Please test Windows

loveucifer · 2026-01-12T09:11:32Z

hmm failed ig 😵‍💫

ahoppen · 2026-01-12T10:55:40Z

swift-format validation failed with the following errors because the swift-format-ignore lines were removed

+ /Users/ec2-user/jenkins/workspace/swift-sourcekit-lsp-PR-macOS/branch-main/build/buildbot_incremental/unified-swiftpm-build-macosx-x86_64/release/swift-format lint --parallel --strict --recursive /Users/ec2-user/jenkins/workspace/swift-sourcekit-lsp-PR-macOS/branch-main/sourcekit-lsp
branch-main/sourcekit-lsp/Sources/SourceKitD/sourcekitd_uids.swift:17:16: error: [TypeNamesShouldBeCapitalized] rename the struct 'sourcekitd_api_keys' using UpperCamelCase; for example, 'Sourcekitd_api_keys'
branch-main/sourcekit-lsp/Sources/SourceKitD/sourcekitd_uids.swift:794:16: error: [TypeNamesShouldBeCapitalized] rename the struct 'sourcekitd_api_requests' using UpperCamelCase; for example, 'Sourcekitd_api_requests'
branch-main/sourcekit-lsp/Sources/SourceKitD/sourcekitd_uids.swift:968:16: error: [TypeNamesShouldBeCapitalized] rename the struct 'sourcekitd_api_values' using UpperCamelCase; for example, 'Sourcekitd_api_values'
ERROR: command `['/Users/ec2-user/jenkins/workspace/swift-sourcekit-lsp-PR-macOS/branch-main/build/buildbot_incremental/unified-swiftpm-build-macosx-x86_64/release/swift-format', 'lint', '--parallel', '--strict', '--recursive', '/Users/ec2-user/jenkins/workspace/swift-sourcekit-lsp-PR-macOS/branch-main/sourcekit-lsp']` terminated with a non-zero exit status 1, aborting

Could you add them back in, ideally in a way that they don’t get removed when re-generating the file 😉

ahoppen · 2026-01-12T13:33:06Z

@swift-ci Please test

ahoppen · 2026-01-12T13:36:53Z

@swift-ci Please test Windows

ahoppen · 2026-01-12T22:08:52Z

Could you add this file to CMakeLists.txt to make the tests pass on Windows?

ahoppen · 2026-01-13T15:34:41Z

@swift-ci Please test

ahoppen · 2026-01-13T21:47:37Z

@swift-ci Please test

loveucifer · 2026-01-14T02:07:53Z

hmm another macos fail :/

ahoppen · 2026-01-14T08:01:13Z

Failures is unrelated. Let’s try again.

@swift-ci Please test macOS

loveucifer · 2026-01-14T13:23:44Z

hmm failed again ig

ahoppen · 2026-01-14T18:14:55Z

Oh, interesting. Almost all the tests failed with error: Exited with unexpected signal code <random signal here>. No idea how that happens. Let’s try again to see if it’s infrastructure or your PR.

@swift-ci Please test macOS

loveucifer · 2026-01-14T18:20:40Z

Oh lol , lets see also i did apply for the member program , been 6 days didnt hear back seems like not upto it :/

PhantomInTheWire · 2026-01-14T22:24:58Z

seems like a github issue again @swift-ci please test macos

ahoppen · 2026-01-15T08:43:36Z

Looking through the logs after the --- Running tests in parallel failed. Re-running tests serially to capture more actionable output. marker, I noticed the following:

We are seeing a sourcekitd crash in testCodeCompletionShowsUpdatedResultsAfterDependencyUpdated, which we really shouldn’t because this is not a test that tests crash recovery of sourcekitd. It’s also the first time that we invoke code completion in the tests, so this is likely an issue with the SourceKit plugin. But even though sourcekitd crashes (which is an XPC service), it shouldn’t take down the SourceKit-LSP test runner itself.

I tested if this might have been introduced by a recent change in SwiftPM but have been unable to reproduce the issue by building SwiftPM from source so far. I’m now testing if this issue is caused by changes in this PR (which I can’t really believe) or if it’s caused by something else by re-triggering CI on #2450. I fear this will boil down to having to build an entire toolchain locally and trying to reproduce it that way.

All that is to say, I’ll take care of it and come back once I know more.

ahoppen · 2026-01-15T08:52:04Z

Update: Also seeing the same failure in swiftlang/indexstore-db#276, so it’s not related to this PR. Now the debugging fun begins.

ahoppen · 2026-01-16T06:32:59Z

Crash should be fixed by: swiftlang/swift#86583. Let's try again.

@swift-ci Please test macOS

ahoppen · 2026-01-16T06:38:21Z

@swift-ci Please test macOS

ahoppen · 2026-01-16T12:17:28Z

Finally 🎉🎉🎉

When you have time, do you mind rebasing the type definition PR and I'll review it next.

loveucifer · 2026-01-16T12:30:13Z

Finally 🎉🎉🎉

When you have time, do you mind rebasing the type definition PR and I'll review it next.

doing it rn hold on :D

loveucifer requested review from ahoppen, hamishknight and rintaro as code owners January 6, 2026 14:15

ahoppen reviewed Jan 6, 2026

View reviewed changes

loveucifer mentioned this pull request Jan 8, 2026

[SourceKit] Add type declaration location to cursorInfo response swiftlang/swift#86381

Closed

loveucifer force-pushed the inlay-hint-go-to-definition branch from bd7d3e0 to f46a31b Compare January 8, 2026 15:31

Add go-to-definition for inlay type hints

564a45b

ahoppen reviewed Jan 9, 2026

View reviewed changes

loveucifer mentioned this pull request Jan 10, 2026

cursorInfo request returns mangled type name instead of USR for key.typeusr swiftlang/swift#86432

Open

loveucifer added 2 commits January 10, 2026 07:00

Add cross-module inlay hint resolve test

9e12af1

loveucifer mentioned this pull request Jan 10, 2026

Implement textDocument/typeDefinition request #2445

Merged

hamishknight reviewed Jan 10, 2026

View reviewed changes

ahoppen reviewed Jan 11, 2026

View reviewed changes

loveucifer force-pushed the inlay-hint-go-to-definition branch from c91c9d7 to 9e12af1 Compare January 11, 2026 11:10

loveucifer added 2 commits January 11, 2026 16:52

Simplify InlayHintResolveData using Position LSPAnyCodable

81610b3

Add generated interface support for SDK types in inlay hints

22e7ac0

ahoppen approved these changes Jan 11, 2026

View reviewed changes

Remove typeDefinition remnants

0695d3c

Run swift-format

ceaf87b

ahoppen enabled auto-merge (squash) January 12, 2026 07:53

Restore sourcekitd_uids from main

0b02672

auto-merge was automatically disabled January 12, 2026 12:32
Head branch was pushed to by a user without write access

ahoppen enabled auto-merge January 12, 2026 13:33

ahoppen reviewed Jan 12, 2026

View reviewed changes

Add InlayHintResolve.swift to CMakeLists.txt

45b1598

auto-merge was automatically disabled January 13, 2026 02:06
Head branch was pushed to by a user without write access

ahoppen mentioned this pull request Jan 15, 2026

Revert commits since 1/12 swiftlang/swift-package-manager#9604

Closed

ahoppen merged commit 61ba0c9 into swiftlang:main Jan 16, 2026
3 checks passed

		// inlay hints store the uri in data for resolution
		// extract uri from the lspany dictionary

Conversation

loveucifer commented Jan 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

loveucifer commented Jan 8, 2026 • edited by ahoppen Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ahoppen commented Jan 8, 2026

Uh oh!

loveucifer commented Jan 8, 2026

Uh oh!

loveucifer commented Jan 9, 2026

Uh oh!

loveucifer commented Jan 9, 2026

Uh oh!

ahoppen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

loveucifer commented Jan 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hamishknight Jan 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ahoppen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

loveucifer commented Jan 11, 2026

Uh oh!

ahoppen commented Jan 11, 2026

Uh oh!

ahoppen left a comment

Choose a reason for hiding this comment

Uh oh!

ahoppen commented Jan 12, 2026

Uh oh!

ahoppen commented Jan 12, 2026

Uh oh!

loveucifer commented Jan 12, 2026

Uh oh!

loveucifer commented Jan 8, 2026 •

edited by ahoppen

Loading

hamishknight Jan 10, 2026 •

edited

Loading

ahoppen commented Jan 12, 2026 •

edited

Loading

ahoppen commented Jan 14, 2026 •

edited

Loading