Fix multiline hyperlink renders #4307
Merged
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
vkryachko
approved these changes
Nov 10, 2022
Size Report 1Affected Products
Test Logs |
davidmotson
pushed a commit
that referenced
this pull request
Nov 28, 2022
* Replace trace hyperlink with direct link * Replace timestamp link with non multiline variant * Add transform to rectify hyperlink bugs in see blocks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Per b/256180692, this PR fixes an issue where multiline
@seeblocks were leaking HTML into the final output for documentation.This occurs due to an upstream issue with Dokka (see Kotlin/dokka#2665), where line breaks inside of
@seetags break the generated Javadoc. This also prevents hyperlinks from being utilized in@seeblocks. Thankfully, this issue only occurs in two places throughout our codebase (at least on the public API, which is what matters for doc generation).One instance was resolved by providing a direct reference to the object- as it just so happens to be present on our classpath (and as such, a hyperlink is not needed).
The remaining instance was solved in three ways:
FiresiteTransformmethod to handle the remaining leakage, and patch it up as expected.The reason for keeping the link on one line and then implementing a transform versus just implementing one to handle the multiline issue is so that we can keep this state to a single issue; hyperlinks not working. Versus being bound to two separate issues; hyperlinks not working AND newlines breaking the output. So should Dockka only fix one of the issues, it will not break our transform.