BuildServerIntegration: thread a request purpose so editor and index build settings don't share a cache entry

[nkcsgexi]

Add a purpose (editor vs index) to the TextDocumentSourceKitOptionsRequest that BuildServerManager sends. buildSettings defaults to .editor; background indexing (UpdateIndexStoreTaskDescription) passes .index. Because purpose is part of the request, editor and index requests occupy separate cachedAdjustedSourceKitOptions entries, so the index settings are computed after preparation and pick up the explicit-modules sidecar instead of reusing the editor's stale entry.

[nkcsgexi]

swiftlang/swift-tools-protocols#86
@swift-ci please test

[nkcsgexi]

swiftlang/swift-tools-protocols#86
@swift-ci please test

[nkcsgexi]

swiftlang/swift-tools-protocols#86
@swift-ci please test

[nkcsgexi]

swiftlang/swift-tools-protocols#86
@swift-ci please test

[ahoppen]

I don’t fully understand the purpose of this. Indexing and editor functionality should be operating on the same build settings and if the explicit modules build has finished, shouldn’t the editor also pick up these modified settings?

[nkcsgexi]

shouldn’t the editor also pick up these modified settings?

You are right that we should also enable EBMs for editor build settings. However, we currently don't have a way to reliably enable EBM for editor functionalities since editor's build setting could be requested before the preparation build is done, and the preparation build is where all the module dependencies are generated. However, we could enable EBM reliably for background indexing build after this change since background indexing always happens after a preparation build.

[nkcsgexi]

swiftlang/swift-tools-protocols#86
@swift-ci please test

[ahoppen]

Requesting editor build settings should be kicking off the file’s preparation. The diagnostics requests even waits for editor preparation. So I don’t see a reason why we can’t wait for EMB to finish for editor settings.

[nkcsgexi]

reason why we can’t wait for EMB to finish for editor settings.

Thinking more about this, I think you are right Alex that the problem here is more about that now preparation can change the compiler arguments, however we never invalidate the stale cache after the preparation build is done. What do you think we call cachedAdjustedSourceKitOptions.clear(isolation: self) { targets.contains($0.target) } inside prepare?

[ahoppen]

What causes different compiler arguments to be returned by the build system once preparation has been done? Ie. how does the build system know that preparation has finished? Ideally, whatever triggers that change in behavior would also be the one that invalidates the build settings in the cache (probably by having the BSP server send a buildTarget/didChange notification to LSP, which invalidates the cache).