Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@AbdullinAM
Copy link
Member

No description provided.

@AbdullinAM AbdullinAM marked this pull request as ready for review September 17, 2025 11:47
@AbdullinAM
Copy link
Member Author

Let me know if you have any ideas what test cases we should also add

Copy link
Collaborator

@whyoleg whyoleg left a 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

Copy link
Contributor

@vmishenev vmishenev left a 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.

@AbdullinAM AbdullinAM force-pushed the abdullin/4015-nested-typealiases branch 5 times, most recently from b19a8c2 to 4e4243a Compare September 29, 2025 11:38
@AbdullinAM AbdullinAM force-pushed the abdullin/4015-nested-typealiases branch from 4e4243a to edb13ce Compare September 29, 2025 11:55
@AbdullinAM AbdullinAM requested a review from whyoleg September 29, 2025 13:07
Copy link
Contributor

@vmishenev vmishenev left a 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.

divergentInstance {
group4 {
+"typealias "
group { groupedLink { +"Foo.A" } }
Copy link
Contributor

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

Copy link
Member Author

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

Copy link
Collaborator

@whyoleg whyoleg left a 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

@AbdullinAM AbdullinAM requested a review from whyoleg October 6, 2025 13:50
Copy link
Collaborator

@whyoleg whyoleg left a 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!

@whyoleg
Copy link
Collaborator

whyoleg commented Oct 7, 2025

The TeamCity IT setup is now fixed, and the CI is green. PR could be merged :)

@AbdullinAM AbdullinAM merged commit b49856b into master Oct 7, 2025
14 checks passed
@AbdullinAM AbdullinAM deleted the abdullin/4015-nested-typealiases branch October 7, 2025 12:58
whyoleg pushed a commit that referenced this pull request Oct 13, 2025
* 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)
adam-enko pushed a commit that referenced this pull request Nov 4, 2025
* 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
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.

4 participants