-
Notifications
You must be signed in to change notification settings - Fork 128
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
Fix availability logic refactor #1065
base: main
Are you sure you want to change the base?
Fix availability logic refactor #1065
Conversation
Sources/SwiftDocC/Infrastructure/Symbol Graph/SymbolGraphLoader.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDocC/Infrastructure/Symbol Graph/SymbolGraphLoader.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDocC/Infrastructure/Symbol Graph/SymbolGraphLoader.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDocC/Infrastructure/Symbol Graph/SymbolGraphLoader.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDocC/Infrastructure/Symbol Graph/SymbolGraphLoader.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDocC/Infrastructure/Symbol Graph/SymbolGraphLoader.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDocC/Infrastructure/Symbol Graph/SymbolGraphLoader.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftDocC/Infrastructure/Symbol Graph/SymbolGraphLoader.swift
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a great step towards making this complex logic both more correct and easier to read.
This refactor was initiated by the need of stop using the module operating system name as an availability item. This change required a big refactoring of the logic, and now the symbol graph availability loading logic is like the following: 1. Every symbol graph is loaded and the symbols get only the availability information that's marked in the SDK. 2. Once all the SGFs are oaded, whe iterate over the symbols and we add the fallbkac and default availability if applies.
61e6e1e
to
ec28dd5
Compare
Instead of making a `[(FallbackPlatform, InheritedPlaform)]. The new struture to hold this information is in the way of `[InheritedPlatfor:[FallbackPlatforms]]`.
@@ -1652,6 +1644,122 @@ class SymbolGraphLoaderTests: XCTestCase { | |||
XCTAssertEqual(availability.first(where: { $0.domain?.rawValue == "macCatalyst" })?.introducedVersion, SymbolGraph.SemanticVersion(major: 1, minor: 0, patch: 0)) | |||
} | |||
|
|||
func testNotAvailableSymbol() throws { | |||
// Symbol from SG | |||
let symbolGraphStringiOS = makeSymbolGraphString( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This variable says iOS but the data says macOS
} | ||
""" | ||
) | ||
let symbolGraphStringMacOS = makeSymbolGraphString( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: and this does the opposite
try symbolGraphStringMacOS.write(to: targetURL.appendingPathComponent("MyModule-macos.symbols.json"), atomically: true, encoding: .utf8) | ||
try infoPlist.write(to: targetURL.appendingPathComponent("Info.plist"), atomically: true, encoding: .utf8) | ||
// Load the bundle & reference resolve symbol graph docs | ||
let (_, _, context) = try loadBundle(from: targetURL) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor: Would it be possible to use the various File
test helpers for this catalog instead of strings?
guard symbolsByPlatformName[defaultAvailability.platformName.rawValue]?.contains(where: { | ||
symbolID == $0.precise | ||
}) != false else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor: AFAICT this is the only place that uses symbolsByPlatformName
. If that's correct, maybe it would be worth using a set of symbol IDs so that this can use contains(_:)
instead of contains(where:)
.
In other words, changing symbolsByPlatformName
from [String: [SymbolGraph.Symbol.Identifier]]
to [String: Set]
platformVersion: fallbackIntroducedVersion | ||
) | ||
platformAvailabilities + DefaultAvailability.fallbackPlatforms.flatMap { (fallbackPlatform, platform) in | ||
platform.compactMap { pla in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This looks like an incomplete word.
platform.compactMap { pla in | |
platform.compactMap { platformName in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These look like good improvements to me.
I left a few very minor suggestions but nothing blocking.
Bug/issue #, if applicable: 139722227
Summary
DocC current logic for determining API availability involves adding the symbol graphs operating system platform name to the final symbol availability.
This approach is problematic because the platform name may not always be in a human-readable format. While it's necessary for calculating availability, we don't want it included as an explicit availability item.
This is a major refactor of the availability logic to not include the symbolgraph operating system platform name as an availability item.
Dependencies
Describe any dependencies this PR might have, such as an associated branch in another repository.
Testing
Review unit tests added.
Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.
./bin/test
script and it succeeded