Skip to content
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

Deprecate two-step documentation context creation #1059

Merged
merged 33 commits into from
Oct 25, 2024

Conversation

d-ronnqvist
Copy link
Contributor

@d-ronnqvist d-ronnqvist commented Oct 15, 2024

Bug/issue #, if applicable: rdar://136208312

Summary

This is the fifth of many changes to redefine how documentation contexts are created.

This PR deprecates the two-step context creation process (first create a context, then register a context-data-provider with it) and the various types used in this two-step process:

  • DocumentationConverter and DocumentationConverterProtocol
  • DocumentationContextDataProvider and DocumentationContextDataProviderDelegate
  • DocumentationWorkspace
  • DocumentationWorkspaceDataProvider
    • GeneratedDataProvider
    • PrebuiltLocalFileSystemDataProvider
    • using LocalFileSystemDataProvider as a DocumentationWorkspaceDataProvider

Most of these changes are about updating tests to use discover inputs first and initialize context with their inputs:

Sources
 23 files changed, 112 insertions(+), 93 deletions(-)
Tests
 36 files changed, 407 insertions(+), 710 deletions(-)

Dependencies

This builds on the changes from #1057 (Pass documentation context its only bundle during initialization)

This diff shows the changes that are new in this PR.

Testing

Nothing in particular. This isn't a user-facing change.

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

  • Added Updated tests
  • Ran the ./bin/test script and it succeeded
  • [ ] Updated documentation if necessary The next PR in this series will update the contributor documentation to reflect these changes.

@d-ronnqvist d-ronnqvist added the code cleanup Code cleanup *without* user facing changes label Oct 15, 2024
@d-ronnqvist
Copy link
Contributor Author

@swift-ci please test

d-ronnqvist added a commit that referenced this pull request Oct 21, 2024
…iew cancellation "" (#1062)

* Revert "Revert "Define commands as asynchronous and use Task for preview canc…"

This reverts commit 61ce635.

* Workaround miscompilation in `ConvertAction.perform(logHandle:)`

* Temporarily skip until `testCancelsConversion()` until #1059 is merged

* Change private `DiagnosticEngine.filter` closure to a private function
@d-ronnqvist
Copy link
Contributor Author

@swift-ci please test

@d-ronnqvist
Copy link
Contributor Author

@swift-ci please test

Copy link
Contributor

@patshaughnessy patshaughnessy left a comment

Choose a reason for hiding this comment

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

Great work!! 👏

@@ -37,6 +38,7 @@ public protocol DocumentationConverterProtocol {
///
/// You can also configure the documentation converter to emit extra metadata such as linkable entities and indexing records
/// information.
@available(*, deprecated, message: "This deprecated API will be removed after 6.2 is released")
Copy link
Contributor

Choose a reason for hiding this comment

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

I noticed a comment near ConvertActionConverter.convert.recordProblem mentions DocumentationConverter - we might want to remove or update that:

These problems only represent unexpected thrown errors and aren't particularly user-facing but because
DocumentationConverter.convert(outputConsumer:) emits them as diagnostics we do the same 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.

I rephrased this comment in 84b0dc0 to add a future action to change it while still mentioning that this current behavior came from DocumentationConverter in case the reader wonders why the code does this today.

@@ -50,9 +50,6 @@ public struct ConvertAction: AsyncAction {
/// - buildIndex: Whether or not the convert action should emit an LMDB representation of the navigator index.
///
/// A JSON representation is built and emitted regardless of this value.
/// - workspace: A provided documentation workspace. Creates a new empty workspace if value is `nil`
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice to see all this simplification!

@@ -12,6 +12,7 @@
import XCTest
@testable import SwiftDocC

@available(*, deprecated, message: "This deprecated API will be removed after 6.2 is released")
Copy link
Contributor

Choose a reason for hiding this comment

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

Interesting I've never see a unit test deprecated before. Does Xcode or SPM run these as usual? Is there an option to skip them? Do we need deprecation warnings during test runs?

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. I usually copy and paste a template comment about this. I don't know why I didn't do that here.

Both Xcode and SwiftPM runs deprecated tests like this without skipping them and without raising deprecation warnings. The reason for marking a test as deprecated is that it allows the test to use other deprecated API without causing deprecation warnings.

I'll find that comment and add it to all the newly deprecated tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added a comment in 0d28c07 to all the deprecated test (that didn't already have it) that explains that the deprecation only silenced other deprecation warnings and that it doesn't skip those tests.


XCTAssertEqual(bundles.count, 1)
guard let bundle = bundles.first else { return }
let fileSystem = try TestFileSystem(folders: [catalog])
Copy link
Contributor

Choose a reason for hiding this comment

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

Aside from being easier to read and simpler, are these tests now using the in-memory file system instead of an actual temporary directory? And are they faster?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, but it's not going to be all that noticeable on the grand scheme of things.

If I look only at the tests in this file, we can see that:

  • testBundleDiscoveryOptions and testBundleFormat are about 2x-3x faster
  • testFirstBundle and testLoadComplexWorkspace are the same (because they're deprecated tests that haven't changed)
  • testCustomTemplatesFound, testNoCustomTemplates, testNoInfoPlist, and testThemeSettingsFound are too fast to register.
Test name on main on this branch
testBundleDiscoveryOptions 0.015 s 0.007 s
testBundleFormat 0.064 s 0.021 s
testCustomTemplatesFound 0.018 s 0.000 s
testFirstBundle 0.021 s 0.021 s
testLoadComplexWorkspace 0.027 s 0.026 s
testNoCustomTemplates 0.013 s 0.000 s
testNoInfoPlist 0.011 s 0.000 s
testThemeSettingsFound 0.016 s 0.000 s

Across those 8 tests this saves about 100ms (0.184 s on main compared to 0.088 s on this branch).

That said, across the entire test suite the difference is still less than a second because very few tests changed to using an in-memory file system and each test is only a few milliseconds speedup.

otherFileSystemDirectories: [Folder] = [],
configuration: DocumentationContext.Configuration = .init()
) throws -> (DocumentationBundle, DocumentationContext) {
let fileSystem = try TestFileSystem(folders: [catalog] + otherFileSystemDirectories)
Copy link
Contributor

Choose a reason for hiding this comment

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

Repeat the previous comment: Are many of our tests now faster, avoiding actually touching the file system?

Great to see this centralized utility used so often in the tests!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, some tests are a few milliseconds faster but the impact on the entire test suite is less than a second.

@d-ronnqvist
Copy link
Contributor Author

@swift-ci please test

@d-ronnqvist d-ronnqvist merged commit ed492be into swiftlang:main Oct 25, 2024
2 checks passed
@d-ronnqvist d-ronnqvist deleted the deprecate-workspace branch October 25, 2024 08:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code cleanup Code cleanup *without* user facing changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants