-
Notifications
You must be signed in to change notification settings - Fork 463
Support for nested typealiases #4261
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
Conversation
|
Let me know if you have any ideas what test cases we should also add |
whyoleg
left a comment
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.
Nice work!
As for additional tests, here is what comes in mind for me:
- check that we handle nested typealias in all classlikes: class, interface, object, enum (not supported only in
annotation class) - check that we correctly resolve link to typealias page if parameter/receiver/return-value of the function/property is type alias
- check that we correctly resolve links
[typealias], mostly AA work here, but still would be nice to check, that we resolve correct DRI/pages -
- maybe something based on the comments
...jetbrains/dokka/analysis/kotlin/symbols/translators/DefaultSymbolToDocumentableTranslator.kt
Show resolved
Hide resolved
dokka-subprojects/core/src/main/kotlin/org/jetbrains/dokka/model/Documentable.kt
Outdated
Show resolved
Hide resolved
...otlin/org/jetbrains/dokka/base/transformers/documentables/DocumentableReplacerTransformer.kt
Show resolved
Hide resolved
dokka-subprojects/core/src/main/kotlin/org/jetbrains/dokka/model/Documentable.kt
Outdated
Show resolved
Hide resolved
.../kotlin/org/jetbrains/dokka/base/transformers/documentables/ExtensionExtractorTransformer.kt
Show resolved
Hide resolved
...ase/src/main/kotlin/org/jetbrains/dokka/base/translators/documentables/DefaultPageCreator.kt
Show resolved
Hide resolved
dokka-subprojects/core/src/main/kotlin/org/jetbrains/dokka/model/Documentable.kt
Outdated
Show resolved
Hide resolved
...ase/src/main/kotlin/org/jetbrains/dokka/base/translators/documentables/DefaultPageCreator.kt
Outdated
Show resolved
Hide resolved
...ase/src/main/kotlin/org/jetbrains/dokka/base/translators/documentables/DefaultPageCreator.kt
Outdated
Show resolved
Hide resolved
...ase/src/main/kotlin/org/jetbrains/dokka/base/translators/documentables/DefaultPageCreator.kt
Outdated
Show resolved
Hide resolved
vmishenev
left a comment
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.
@whyoleg provided a good review.
It would be nice to check not only the Content model, but also the Documentable model.
Also, some tests can be edited/added for each modified transformer, e.g.
dokka/dokka-subprojects/plugin-base/src/test/kotlin/filter/KotlinArrayDocumentableReplacerTest.kt
Line 118 in f524273
| fun `typealias with array type`() { |
...ain/kotlin/org/jetbrains/dokka/base/transformers/pages/annotations/SinceKotlinTransformer.kt
Outdated
Show resolved
Hide resolved
.../dokka/base/transformers/documentables/SuppressedByConditionDocumentableFilterTransformer.kt
Show resolved
Hide resolved
dokka-subprojects/core/src/main/kotlin/org/jetbrains/dokka/model/Documentable.kt
Show resolved
Hide resolved
b19a8c2 to
4e4243a
Compare
…ing if the classlike was changed
4e4243a to
edb13ce
Compare
vmishenev
left a comment
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.
Is there a test for SuppressedByConditionDocumentableFilterTransformer?
E.g.
dokka/dokka-subprojects/plugin-base/src/test/kotlin/transformers/SuppressTagFilterTest.kt
Line 116 in d4d457d
| fun `should filter top level type aliases`() { |
| divergentInstance { | ||
| group4 { | ||
| +"typealias " | ||
| group { groupedLink { +"Foo.A" } } |
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.
Sorry, I haven't noticed.
Should we render a nested typealias as A or Foo.A?
cc @whyoleg
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 that to be more consistent, we need to show only A in the typealias declaration itself, and Foo.A in the use-cases. This will be similar to how nested classes are displayed currently
whyoleg
left a comment
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.
Nice!
Please, fix the ABI, similar to how it's done in #4080, and we are good to go
...jetbrains/dokka/analysis/kotlin/symbols/translators/DefaultSymbolToDocumentableTranslator.kt
Show resolved
Hide resolved
...s/plugin-base/src/main/kotlin/org/jetbrains/dokka/base/signatures/KotlinSignatureProvider.kt
Outdated
Show resolved
Hide resolved
dokka-subprojects/core/src/main/kotlin/org/jetbrains/dokka/model/Documentable.kt
Show resolved
Hide resolved
…typealiases, replace it with custom implementation
whyoleg
left a comment
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.
Nice! Thanks for fixing all the remarks!
|
The TeamCity IT setup is now fixed, and the CI is green. PR could be merged :) |
* Add `WithTypealiases` interface to documentables * Copy typealiases everywhere * Merge typealiases in multiplatform projects * Fix DocumentableReplacerTransformer: consider typealiases when computing if the classlike was changed * Add test for nested typealiases in SuppressTagFilterTest.kt * Change the rendering of typealias names * Ensure ABI compatibility of documentables that implement `WithTypealiases` * Add test that checks nested typealiases with type parameters * Remove the use of `signatureForProjection` in `regularSignature` for typealiases, replace it with custom implementation (cherry picked from commit b49856b)
* Add `WithTypealiases` interface to documentables * Copy typealiases everywhere * Merge typealiases in multiplatform projects * Fix DocumentableReplacerTransformer: consider typealiases when computing if the classlike was changed * Add test for nested typealiases in SuppressTagFilterTest.kt * Change the rendering of typealias names * Ensure ABI compatibility of documentables that implement `WithTypealiases` * Add test that checks nested typealiases with type parameters * Remove the use of `signatureForProjection` in `regularSignature` for typealiases, replace it with custom implementation
No description provided.