Listening for diagnostics from SourceKit: how to tell what version of the file they came from?

I have a question that's somewhat related to the VFS stuff that I have been thinking about (Injecting a custom FileSystem into SourceKit? - #5 by marcrasi, https://github.com/apple/swift/pull/24417, add custom fs to editor.open by marcrasi · Pull Request #1 · marcrasi/swift · GitHub), but I think it's independent enough to deserve its own thread.

We have noticed that if we send "editor.open" requests with file contents to SourceKit, we asynchronously get back "source.notification.compile-did-finish" notifications with diagnostics.

There seems to be nothing in the notification allowing us to associate it back with a particular "editor.open" request, so we can't tell which version of a file's contents the diagnostics refer to.

Is there some way to receive diagnostic information from SourceKit with information about exactly which version of a file it refers to? If not, would it be reasonable to add a feature to SourceKit that allows us to make this association? Maybe allow the client to specify a token with each "editor.open" request, and then pass that token back to the client in "source.notification.compile-did-finish" notification?

cc @akyrtzi @blangmuir

From what I can see in Requests.cpp, the compile-will-start notification contains file path and compiler args (both passed from editor.open) as well as a compiler id. In turn, the compile-did-finish notification contains a compiler id.

A token sounds like a convenient and reliable way to correlate editor.open and subsequent notifications. I like this idea, and, from what I can see, I think it would be great if it would be approved for inclusion in a future version of SourceKit.

Additionally, in the meanwhile, I think it may be possible to hack something up even in the current state of things by passing this token through file path and/or compiler args (and then associating it with a compile id upon receiving compile-will-start): 1) given a custom VFS, the file path could not only include a real path but also the underlying token, e.g. /path/to/file.swift@token, 2) compiler arguments could include a fake argument like -DREQUEST_TOKEN=token.

compile-did-finish is intended for logging purposes, it's not how you are supposed to get the diagnostics for a file. The intended way is to have an editor.open document and once you receive a notification that semantic info changed, you do an empty edit request to get latest up-to-date semantic info. The returned info will match the source state that the document contains at that point.

For more details see what the sourcekitd-test -req=sema command is doing.