Skip to content

Conversation

@franklinsch
Copy link
Contributor

@franklinsch franklinsch commented Mar 4, 2022

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

Summary

Filters out topics that aren't available in the language of the symbol that curates them. Note that this was already working for automatically curated topics, but not manually curated topics.

This PR also includes making tutorial content available on all the languages in which the framework is available (last commit),

Also, since the original fix of this PR filters out topics that aren't available in the parent page's language, it was also causing DocC to filter out tutorial content from Objective-C pages. As such, the last commit of this PR resolves this issue by making tutorials multi-language as well, if the framework it's documenting is multi-language.

Dependencies

None.

Testing

  1. Create symbol graph files with symbols that are only available in Swift and symbols only available in Objective-C, and curate them manually in a documentation extension file or in documentation comments.
  2. Verify that the rendered documentation doesn't show the Objective-C–only symbols when browsing the Swift documentation, and vice-versa.

Checklist

  • Added tests
  • Ran the ./bin/test script and it succeeded
  • Updated documentation if necessary

TODO

  • Make Tutorials multi-language so that they can be curated in Objective-C pages. They're currently hardcoded to be Swift-only

@franklinsch franklinsch force-pushed the filter-topics-languages branch from 663153b to f9b5518 Compare March 7, 2022 12:43
@franklinsch franklinsch changed the title [WIP] Filter out topics that aren't available in the page's language Filter out topics that aren't available in the page's language Mar 7, 2022
@franklinsch franklinsch marked this pull request as ready for review March 7, 2022 12:43
@franklinsch
Copy link
Contributor Author

@swift-ci please test

@franklinsch franklinsch force-pushed the filter-topics-languages branch from f9b5518 to 4cd124c Compare March 7, 2022 13:39
@franklinsch franklinsch requested review from d-ronnqvist and ethan-kusters and removed request for ethan-kusters March 7, 2022 13:39
@franklinsch
Copy link
Contributor Author

@swift-ci please test

@franklinsch
Copy link
Contributor Author

@swift-ci please test

}

/// Creates an empty grouped sequence.
init(deriveKey: @escaping (Element) -> Key) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: typo derivedKey

Copy link
Contributor Author

@franklinsch franklinsch Mar 9, 2022

Choose a reason for hiding this comment

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

I think deriveKey as it is currently works better because its type is a function, so it should be named like an action.

/// // Prints "a"
/// // Prints "aaa"
/// ```
struct GroupedSequence<Key: Hashable, Element>: Sequence, CustomStringConvertible {
Copy link
Contributor

Choose a reason for hiding this comment

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

Not needed for this PR but this already fulfills the requirements for Collection might be nice since we are making this a standalone data structure.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hm, yes, looks like we're close! But we need to implement a few more requirements, which I think we should implement when we get a use for them. This isn't intended to be a general-purpose API—it's just for DocC's purposes.


/// Returns whether the topic with the given identifier is available in one of the traits in `allowedTraits`.
func isAvailableInAllowedTrait(identifier: String) -> Bool {
guard let reference = contentCompiler.collectedTopicReferences[identifier] else {
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure I understand this logic. Could you explain why you return true if you couldn't find a topic reference for this identifier?

Copy link
Contributor

Choose a reason for hiding this comment

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

Is this because you are conservatively not filtering out content you don't have a definition for in this framework?

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 yes, I should clarify that in a comment, thanks for pointing that out. It's expected for reference to never be nil as it is a precondition for contentCompiler to have populated collectionTopicReference with the reference at this point. Otherwise, it is a bug in contentCompiler.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In fact, we can actually add an assertionFailure so that we get a crash in debug builds, but not release.

Copy link
Contributor Author

@franklinsch franklinsch Mar 9, 2022

Choose a reason for hiding this comment

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

Actually, after taking a closer look, I'm wrong on this. It's possible for the content compiler to generate a reference identifier without registering it in collectedTopicReferences, for example when the reference is a non-doc URL, e.g., https:// in which case it gets registered in linkReferences instead. I'll add a comment to clarify that.

groupedSequence.append("aa")

XCTAssertEqual(groupedSequence[1], "a")
XCTAssertEqual(groupedSequence[2], "aa")
Copy link
Contributor

@daniel-grumberg daniel-grumberg Mar 8, 2022

Choose a reason for hiding this comment

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

you probably want to add the following to this:

groupedSequence.append("b")
XCTAssertEqual(groupedSequence[1], "b")

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, that's a great idea!

@franklinsch franklinsch force-pushed the filter-topics-languages branch from a2eb297 to 906ac34 Compare March 9, 2022 13:19
@franklinsch
Copy link
Contributor Author

@swift-ci please test

Copy link
Contributor

@ethan-kusters ethan-kusters left a comment

Choose a reason for hiding this comment

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

This looks good to me! Just a few small things for your consideration.

Was tutorials the last thing we needed to support here or do we still need support for articles?

semantic: technology
)
documentationCache[reference] = node
topicGraph.nodes[reference]?.reference = reference
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a change from before? We weren't including technology references in the topic graph?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are at an earlier stage, in registerDocuments. What we're doing here is updating the reference now that we have enough information to know in which languages the page is available in. I'll add a comment to clarify that.

}

/// Returns whether the topic with the given identifier is available in one of the traits in `allowedTraits`.
func isAvailableInAllowedTrait(identifier: String) -> Bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
func isAvailableInAllowedTrait(identifier: String) -> Bool {
func topicIsAvailableInAllowedTraits(identifier topicIdentifier: String) -> Bool {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair. I can meet in the middle with isTopicAvailableInAllowedTraits. 🤝?

Copy link
Contributor

Choose a reason for hiding this comment

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

Deal. 🤝😃

@franklinsch franklinsch force-pushed the filter-topics-languages branch from 906ac34 to 64e6daf Compare March 10, 2022 15:08
@franklinsch
Copy link
Contributor Author

Was tutorials the last thing we needed to support here or do we still need support for articles?

I believe tutorials was the last thing we needed to make multi-language. Article support was added by #81.

Filter out topics that are not available in the language of the symbol
that curates them.

rdar://89124291
In the same way articles do, infer the available languages of tutorials
from the module's available language.
@franklinsch franklinsch force-pushed the filter-topics-languages branch from 64e6daf to a7857b3 Compare March 10, 2022 15:12
@franklinsch
Copy link
Contributor Author

@swift-ci please test

@franklinsch
Copy link
Contributor Author

@swift-ci please test macOS platform

@franklinsch
Copy link
Contributor Author

@swift-ci please test Linux platform

documentationCache[technologyReference] = technologyNode

// Update the reference in the topic graph with the technology's available languages.
topicGraph.updateReference(
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice! This looks great- much easier for me to follow.

@franklinsch franklinsch merged commit 783cc96 into swiftlang:main Mar 11, 2022
@franklinsch franklinsch deleted the filter-topics-languages branch March 11, 2022 17:40
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