[Sourcekitl-lsp] Finding out what paths are being used for the index store lookup

Development SourceKit-LSP
1

Hey all, a quick question here

I'm trying to figure out what paths are being used for the index store lookup for my sourcekit lsp. I'm not interested in the index-store path itself and where the sourcekit-lsp is consuming it from, but what is being used in sourcekit-lsp when looking up the indexes for each file. I believe it used to be provided via the output paths request in the BSP but it is no longer the case.

Thanks in advance

2

I don’t think I fully understand your question but let me give you some background. Maybe it answers them.

  • The BSP output paths requests from BSP was never used.
  • At the moment SourceKit-LSP doesn’t use output file paths either, with matches unit files to source files based on the main-path in the unit file.

Is your question just curiosity or are you seeing an issue? Maybe describing the issue will help clarify your question.

3

Could you point me to the code for this? This is mainly a question as I'm working on some index-store generation logic. Is it possible to trace a request to get the exact path used for a given input in the sourcekit-lsp?

Basically for each source file, I was under the impression that it needs to match up to what is used in sourcekit-lsp when looking up the indexes for each file, and I thought this was provided via the output paths in the BSP

4

SourceKit-LSP’s entry point to the index is CheckedIndex.swift.

I think that we don’t actually match output paths at the moment, but I might be misremembering things.

5

I'm trying to confirm that is the case, since its crucial for my index store generation. I've been trying to follow the codepath through, but can't seem to find it. Is there a way to get to the logging at this level to inspect the filepath thats being looked up? I've tried to make it as verbose as possible with sourcekit logging but havent found success when digging through the logs

6

What exactly do you mean by looking up the index for a file? We generally use the AST and not the index to serve local queries (like jump-to-definition and code completion) and only consult the index for global queries like global rename and call hierarchy. sourcekit-lsp/Contributor Documentation/Background Indexing.md at main · ahoppen/sourcekit-lsp · GitHub has some information about this at the start.

Because of this, the entry point into the index is generally something like “give me all references to this USR” and not something like: Give me information about this file.

7

Thanks, this helped tremendously.

Basically interested in the part here

return index.occurrences(ofUSR: usr, roles: roles).compactMap { indexToLSPLocation($0.location) }

where I'm trying to trace the logic thats producing the USR to see where that is filled. It looks like its using location.path, and so I want to see what path that is exactly if that makes sense?

Maybe its here? sourcekit-lsp/Sources/SourceKitLSP/Swift/CursorInfo.swift at main · swiftlang/sourcekit-lsp · GitHub its using requests.cursorInfo?

8

Yes, the USR is coming from the cursor info request.

9

and from what I gather, cursor info request is able to just obtain the file path / location of the files I am currently looking at?

e.g. if I have a file open in /foo/bar/sourcefile.swift, cursor info request will send the absolute path as is?

If so, to summarize, theres no output path matching done with the index store. However when doing something like a goto def outside a module, it needs to access the global index, which it accesses the indexx basically saying "Give me all references to this USR".

The initial USR built into the index stores are absolute paths, is that correct? so /foo/bar/sourcefile.swift in this case will match the USR in the request from my cursor info, which would also be /foo/bar/sourcefile.swift?

10

Cursor info will use the name of the file that you pass in LSP’s textDocument/didOpen for the file name. It will also use compiler argument that are provided by the build system (SwiftPM, compile_commands.json, or BSP server). You can see those arguments by inspecting the logging as described in sourcekit-lsp/CONTRIBUTING.md at main · swiftlang/sourcekit-lsp · GitHub

For jump to definition, SourceKit-LSP will ask for all definitions of the USR, not all references, but yes, essentially that’s correct. I think that we do need to add some output path matching in the future to discard records in the index for files that are no longer in your build but I haven’t looked into it enough to give you information at a detail level yet.

1 Like