Keep track of build settings in BuildSystemManager instead of SourceKitServer
#841
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ahoppen
force-pushed
the
ahoppen/build-settings-pull
branch
from
ea6158f to
9a2c57f
Compare
|
@swift-ci Please test |
|
@swift-ci Please test macOS |
…mManagerTests` to get build settings
…not about new build settings This defines away an entire class of data races if delegate callbacks are delivered out-of-order. If we aren’t providing the new build settings in the delegate callback, then it doesn’t matter if two `fileBuildSettingsChanged` calls change order since they don’t carry any state.
…d `BuildSystemManager` The core idea here is that the toolchain language servers always call into `BuildSystemManager` and `BuildSystemManager` will always reply with build settings. If it hasn’t computed them yet, it will reply with fallback settings. With that assumption, we can remove the `documentToPendingQueue` from `SourceKitServer` since there are no longer any documents that are pending – everything has a build settings immediately. Similarly, `BuildSystemManager.mainFileStatuses` also isn’t needed anymore. And lastly, since we know that `BuildSystemManager.buildSettings` will always return a value `registerForChangeNotifications` is changed not call `fileBuildSettingsChanged` immediately. Instead, it will only cause `fileBuildSettingsChanged` to be called when the file’s build settings change after the `registerForChangeNotifications` call.
ahoppen
force-pushed
the
ahoppen/build-settings-pull
branch
from
9a2c57f to
c642b37
Compare
hamishknight
approved these changes
Oct 2, 2023
| for document: DocumentURI, | ||
| language: Language | ||
| ) async -> (buildSettings: FileBuildSettings, isFallback: Bool)? { | ||
| if let mainFile = mainFilesProvider?.mainFilesContainingFile(document).first { |
There was a problem hiding this comment.
As I understand it, mainFilesContainingFile returns a Set, do we need to worry about the lack of a stable ordering when accessing first?
There was a problem hiding this comment.
Ah I see this is copying chooseMainFile, do we need to worry there too?
There was a problem hiding this comment.
It turned out that this was a good area to refactor and it got a little bit larger and more involved. I will open a follow-up PR for it.
Comment on lines
-273
to
-284
| // If the document is ready, we can handle it right now. | ||
| guard !self.documentsReady.contains(doc) else { | ||
| await requestHandler(request, workspace, languageService) | ||
| return | ||
| } | ||
|
|
||
| // Not ready to handle it, we'll queue it and handle it later. | ||
| self.documentToPendingQueue[doc, default: DocumentNotificationRequestQueue()].add(operation: { | ||
| await requestHandler(request, workspace, languageService) | ||
| }, cancellationHandler: { | ||
| request.reply(fallback) | ||
| }) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After two minor preliminary commits, there are two core commits here that go hand-in-hand and significantly simplify the build settings handling.
Change the build system to only notify delegate about changed files, not about new build settings
This defines away an entire class of data races if delegate callbacks are delivered out-of-order. If we aren’t providing the new build settings in the delegate callback, then it doesn’t matter if two
fileBuildSettingsChangedcalls change order since they don’t carry any state. Instead of storing the build settings returned by the delegate call, the language server needs to ask theBuildSystemManagerfor the current build settings of the file.Remove tracking of file build settings status in
SourceKitServerandBuildSystemManagerThe core idea here is that the toolchain language servers always call into
BuildSystemManagerandBuildSystemManagerwill always reply with build settings. If it hasn’t computed them yet, it will reply with fallback settings.With that assumption, we can remove the
documentToPendingQueuefromSourceKitServersince there are no longer any documents that are pending – everything has a build settings immediately.Similarly,
BuildSystemManager.mainFileStatusesalso isn’t needed anymore.And lastly, since we know that
BuildSystemManager.buildSettingswill always return a valueregisterForChangeNotificationsis changed not callfileBuildSettingsChangedimmediately. Instead, it will only causefileBuildSettingsChangedto be called when the file’s build settings change after theregisterForChangeNotificationscall.