Kotlin: extract annotations #11258
Open
Kotlin: extract annotations #11258
+1,889
−718
Conversation
This file contains 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
igfoo
reviewed
Nov 14, 2022
| logger.warnElement("Expected container class to have a primary constructor", containerClass) | ||
| return null | ||
| } else { | ||
| return IrConstructorCallImpl.fromSymbolOwner(containerClass.defaultType, containerConstructor.symbol).apply { |
There was a problem hiding this comment.
Generating IR makes me nervous. I wonder whether it might be simpler to directly extract the list of annotations, rather than making an IR representation and extracting that?
| @@ -4101,6 +4451,163 @@ open class KotlinFileExtractor( | |||
| extractExpressionExpr(loop.condition, callable, id, 0, id) | |||
| } | |||
|
|
|||
| @Suppress("UNCHECKED_CAST") | |||
| private fun <T : DbExpr> exprIdOrFresh(id: Label<out DbExpr>?) = id as? Label<T> ?: tw.getFreshIdLabel() | |||
There was a problem hiding this comment.
I think we can avoid the warning suppression here by using something like id?.cast() ?: tw.getFreshIdLabel()
tamasvajk
reviewed
Nov 15, 2022
| tw.writeExprs_stringliteral(id, type.javaResult.id, parent, idx) | ||
| tw.writeExprsKotlinType(id, type.kotlinResult.id) | ||
| extractExprContext(id, locId, enclosingCallable, enclosingStmt) | ||
| tw.writeNamestrings(toQuotedLiteral(v.toString()), v.toString(), id) |
There was a problem hiding this comment.
This change results in a lot of changes to expected files. Would it make sense to do this in a separate PR to make the diff cleaner?
| @@ -450,7 +464,406 @@ open class KotlinFileExtractor( | |||
| extractDeclInitializers(c.declarations, false) { Pair(blockId, obinitId) } | |||
| } | |||
|
|
|||
| val jvmStaticFqName = FqName("kotlin.jvm.JvmStatic") | |||
| // Adapted from RepeatedAnnotationLowering.kt | |||
There was a problem hiding this comment.
This file is already quite large, can we easily move these adapted functions into a separate file?
This gives all annotations and expressions derived from them globally-significant and stable names, enabling the Kotlin and Java extractors to see the same annotation without introducing database conflicts.
Note however this includes extracting annotations for external types, unlike the situation for function bodies.
These are due to changing string literal representation, omitting empty annotations blocks, and changes to how annotation classes are represented in the database.
… ignoring the Metadata annotation
smowton
force-pushed
the
smowton/feature/kotlin-annotation-extraction
branch
from
a719a86
to
37e3ecd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This establishes annotation extraction on a par with the Java extractor (annotations for classes/interfaces, value parameters, fields, callables, and enum entries, but noteworthily not for type parameters or type usages, which require database schema work.) Not annotating type usages particularly means that we don't yet need to worry about nullability annotations.
Wrinkles: