Skip to content

Swap BuildSystem to remove build settings method #183

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jun 1, 2020

Conversation

DavidGoldman
Copy link
Contributor

Instead the BuildSystem should inform its delegate of changes to build settings via fileBuildSettingsChanged

@benlangmuir
Copy link
Contributor

@swift-ci please test

@DavidGoldman
Copy link
Contributor Author

Friendly ping

}
}

extension BuildServerBuildSystem: BuildSystem {

/// Register the given file for build-system level change notifications, such as command
/// line flag changes, dependency changes, etc.
public func registerForChangeNotifications(for url: LanguageServerProtocol.URL) {
public func registerForChangeNotifications(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build server still has a settings request; I think we need to make that request here to get the initial settings.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I believe this is still necessary right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rmaz what do you think? should we change the protocol or manually fetch the settings here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The register request should be enough to get the settings, the initial settings should be returned as soon as they are available. I don't believe we need the textDocument/sourceKitOptions request any more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, left this as is, we can remove the textDocument/sourceKitOptions in a follow up if this is working well

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way FileOptionsChangedNotification and registration is setup does not play nicely with files that are outside the build model. Right now, if a file is not known to the build server, it's not clear if it will fail to register (in which case it will not get a notification if it is later added), or if it will register but not provide initial "nil" settings (since FileOptionsChangedNotification does not have a way to represent lack of settings). For the same reason, a file that successfully registers will never have its settings removed.

In the previous model, we could handle this because the settings update would trigger re-querying the settings synchronously, which can fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the server can tell that the file is outside, it should fail registration (and we handle that OK). Otherwise it should provide initial nil settings.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What will happen in these two cases?

  1. file that starts unknown to build system is added to the build system (e.g. after you edit a config file). Do we ever get notified of the settings? I'm guessing not since registration failed.

  2. file that is known by the build system is removed from the build system. How can we be notified that this happened when the update notification has no notion of nil/removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, by If the server can tell that the file is outside, it should fail registration (and we handle that OK). Otherwise it should provide initial nil settings. I meant that the server should only fail registration if it knows that file can never be handled by the build system (e.g. for a monorepo this happens if it's in a different directory). Unless it can do that it should register and provide no settings.

re #2 hmm this we won't handle, @rmaz what do you think?

@DavidGoldman
Copy link
Contributor Author

As mentioned in https://forums.swift.org/t/sourcekit-lsp-file-status-ux/3594, planning on reviving this soon.

- Still need to update all of the `BuildSystem`s and tests

Change-Id: I3d9cd921c650f782bbfa0628a85763cbf838e5cb
- With the `settings(for:)` method removed, we instead block on a
  callback from the `BuildSystemManager` which itself handles
  the primary build system callback in conjunction with the fallback
  system

- We queue up notifications / requests that reference documents.

TODO:
- Full queueing for some text doc modifications, including save/edits.
- Revisit test timeouts + modify BSM fallback timeout for tests

Change-Id: I7cb24145cb87470a7b4701dc3b96c59ab18543c9
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

1 similar comment
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

- Add more comments
- willSave/didSave should be queued as well as changeDocument
- Make the new BuildSystem requirements more clear
- Remove the DispatchTimeInterval comparison check due to
  https://bugs.swift.org/browse/SR-6310, should not be needed anyway

Change-Id: I6992b0cdba54ab6b4ccde304f8a2aecbba9e496a
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

1 similar comment
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

Change-Id: I0436f9d854dfa85ff76e098e7c07b2c14c071d14
- Use the queue to update the language mapping
- Handle register request failure

Change-Id: I7fb19e518e134e3aeec2e4282d6298701ae48fce
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

1 similar comment
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

Copy link
Contributor

@benlangmuir benlangmuir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the build system changes; still need to do a pass over the langauge server changes. Looking really good, thanks!

- Fixes for BuildSystemManager and other BuildSystems
- Remove language from FileBuildSettings as it is no longer needed,
  Swift-specific working dir fixes are now in SwiftCompileCommand

Change-Id: Idff4371e6f6961c2c49998e9cb1dd0dd248da034
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

2 similar comments
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

// No need to send the notification since it was never considered opened.
self.documentToPendingQueue[uri]?.cancelAll()
self.documentToPendingQueue[uri] = nil
self.documentsReady.insert(uri)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it considered ready here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oof nice catch, should instead be a removal above

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This got marked as resolved by the code still has self.documentsReady.insert(uri). Did this change get missed/dropped?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

- registerForChangeNotifications should inform its delegate
  asynchronously instead of immediately
- Use [weak self] for the pending requests/notifications
  to prevent retain cycle if we don't get a settings callback
- Fix for never removing readyDocuments

Change-Id: Id5c183bcc6a99f11b95bf8bfd8b9a93b3af39733
- Another `Language` param removal

Change-Id: Ib1ebb7f2fee8f77a22c48438b80b197447041ae5
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

2 similar comments
@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

@DavidGoldman
Copy link
Contributor Author

@swift-ci please test

@DavidGoldman DavidGoldman merged commit cf19900 into swiftlang:master Jun 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants