-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Kotlin: stub trap .class files when extracting a class from Kotlin source #11510
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
Kotlin: stub trap .class files when extracting a class from Kotlin source #11510
Conversation
ff2d27b
to
6c79985
Compare
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.
Added some minor comments/questions.
…ected kinds of top-level declaration
Only top-level non-class declarations need the IrFile's expected class name inserting
These resulted from the Java compiler exploring NotNull and other Kotlin-emitted annotations, which it no longer does because it finds a .class trap file already present and truncates its class-graph walk
These occur because the Companion field is odd, being extracted from source but not having an associated FieldDeclaration, leading to PrintAst enumerating the node differently depending on whether it has a source-file location or not but in either case choosing not to show it.
This was testing that a signature inconsistency occurs, but this now manifests as a db inconsistency which can't be used as a test expectation because specific tuple numbers are liable to change with the environment.
…a signature We could revert this by allowing useType to avoid triggering class-instance extraction when used just for its signature result
This is actually a bug, which we should follow up on subsequently.
6c79985
to
fc3ed22
Compare
fc3ed22
to
00f323c
Compare
@tamasvajk all comments addressed, and test changes accepted -- two notable changes that were needed: |
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.
Looks okay to me apart from some CI test failures. I also added a minor comment.
@tamasvajk done |
This will be useful for annotations, because other extractors are less likely to see a binary version of the class stripped of its source-only annotations and introduce an inconsistency.