(This post is about providing context about what I'm trying to achieve with PR #693)
The workflow of an IDE/editor interacting with SourceKit-LSP for semantic functionality, like code-completion, should be as follows:
Once the user opens a file in the IDE/editor:
- The build system should send the compiler arguments for the file to SKLSP ASAP. SKLSP will use the compiler arguments to create a compiler AST and offer semantic functionality ASAP.
- At the same time, SKLSP will ask the build system to do a "prepare" operation for that file, so that build artifacts & dependencies for that file can be created/updated. Once the operation completes SKLSP will react accordingly, potentially updating its state, like discarding the existing AST and creating a new more accurate one.
Note that this workflow optimizes for low latency, with eventual accuracy, than high latency. Depending on the state of the project (is it built before, what is the file depending on, etc.) step #1 may offer satisfactory functionality for the user without needing to wait for #2. Even if #1 has missing pieces, #2 will bring the functionality up to high accuracy.
PR #693 fits within this workflow like this: once #2 completes I would like a way for SKLSP to know whether any of the build artifacts & dependencies have been updated since step #1, so that SKLSP can discard its current state and AST and create a new one, or whether the build artifacts & dependencies are still up-to-date for #1, meaning SKLSP does not need to unnecessarily discard its state and AST.
To determine this it is not precise for the build system to just report whether it did something when running #2 operation, because:
- If a swift source file has been touched, swift compiler will be invoked as part of #2 to update the swift module, but if the module interface did not change then the module file won't get updated.
This would be a case where the build system did invoke a task but the dependencies were not actually updated.
#2 may get pre-empted by another "prepare" operation for a different file, cancelled, and then restarted. The second operation that pre-empted it may happen to bring the build artifacts & dependencies of the first one up-to-date because they showed up in its dependencies graph. Because of this, when the first operation restarts it will perform no task.
This would be a case where the build system did not invoke any task, but the dependencies were actually updated since #1.
To have a precise mechanism to determine the state of build artifacts & dependencies, I opened PR #693 to offer a way for an llbuild client to directly inspect the dependency nodes of the node that it built. This offers the flexibility to implement the inference for SKLSP purposes.
Let me know what your thoughts are