[SourceKit] Add type declaration location to cursorInfo response

[loveucifer]

following the pr in swift/sourcekitlsp swiftlang/sourcekit-lsp#2436 i made an attempt to fix this issue swiftlang/sourcekit-lsp#2318. ( a new commit will be added once im done with this )

Changes

extends the cursorInfo request to return complete type declaration location information, enabling proper go-to-definition functionality for inlay type hints in SourceKit-LSP.

Problem

the existing key.typeusr field returns a type-mangled USR (e.g., $sSiD for Int) rather than a declaration USR (e.g., s:Si). type-mangled USRs cannot be used to look up definitions in the index.

Fixes I Made

add new fields to the cursorInfo response:

• key.typedecl_usr - Declaration USR for index lookup
• key.typedecl_filepath - Direct path to declaration
• key.typedecl_line / key.typedecl_column - Line and column
• key.typedecl_modulename - Containing module

Short Summary Of File Changes I made

• LangSupport.h: Added TypeDeclUSR, TypeDeclLocation, TypeDeclModuleName to CursorSymbolInfo
• SwiftSourceDocInfo.cpp: Extract nominal type declaration from variable's type
• Requests.cpp: Output new fields in response
• UIDs.py: Define new key identifiers

also i might have missed something , i started reading the repo only like 2 days ago , but the fix for that led me here so we do what we gotta do :D

[hamishknight]

Thanks for the PR! Rather than adding more things to the cursor info request I think it would be worth seeing if we could add a new request for this that takes the type USR as an input and returns the declaration USR + location info. We already have Demangle::getTypeDeclForMangling which is able to take a mangled type and return its TypeDecl *, you should be able to use that here.

[hamishknight]

When formatting changes please use git clang-format instead to ensure only the bits of code you changed get formatted

[loveucifer]

got it

[loveucifer]

Thanks for the PR! Rather than adding more things to the cursor info request I think it would be worth seeing if we could

hey @hamishknight I am implementing the new source.request.typedecl.info request that takes the mangled type as input (key.mangled_type) and uses Demangle::getTypeDeclForMangling to resolve it, returning the declaration USR + location info.
i had one question: should the response reuse existing keys (key.usr, key.filepath, key.line, key.column) or use prefixed keys like key.typedecl_usr, key.typedecl_filepath etc. to keep them distinct? and could ya also explain why its a better choice( whichever option we pick of course )

[hamishknight]

Oh sorry I just noticed it looks like cursor info already has an option to take a type USR (usingkey.usr) and will decode using getTypeDeclForUSR. So I actually think you may already be able to use that here. I think the only thing you need to do is first convert the mangled name to a USR, but that should be as simple as replacing the $s prefix with s: before querying. Really we ought to consider changing cursor info such that it returns the type USR as a proper USR rather than a mangled name, we'd need to audit the existing clients to make sure they can handle that though.

[loveucifer]

Oh sorry I just noticed it looks like cursor info already has an option to take a type USR (usingkey.usr) and will decode

Should I also update cursorInfo to return key.typeusr as a proper USR instead of a mangled name, or leave that for a separate PR due to the client audit needed?

[hamishknight]

Let's leave that as a separate PR for now, just make the logic in LSP conditional i.e if we have a $s prefix replace with s:

[loveucifer]

Let's leave that as a separate PR for now, just make the logic in LSP conditional i.e if we have a $s prefix replace with s:

wait but wouldnt that mean this pr is now not neeeded at all :0 or am i missing something , should i just close this then and update the pr on swiftlang/sourcekit-lsp ? or is there any sort of addition needed here

[hamishknight]

Yup, assuming it works fine on the LSP side you can close this :)