A modern programming language that makes developers happier.

kotlinlang

What scenarios in FIR would cause an `Array&lt;KClass&lt;*&gt;&gt;` in an annotation to contain a mix of resolved and unresolved classes (from the command line)? I'm trying a to find a through-line that explains why some are unresolved while others that appear to follow the same structure are resolved. Or is it just down to which classes the compiler has seen up to that point?

and perhaps as a followup - is there a way to defer my extension from running until all those arguments are resolved during supertype generation?

&gt; What scenarios in FIR would cause an Array&lt;KClass&lt;*&gt;&gt; in an annotation to contain a mix of resolved and unresolved classes (from the command line)?
That sounds suspicious, at the supertypes stages no arguments should be resolved except some special cases (<https://github.com/JetBrains/kotlin/blob/100d3cd87bad77cd05db946ae2ba6635e7379a56/compiler/fir/tree/src/org/jetbrains/kotlin/fir/declarations/FirResolvePhase.kt#L109|doc>).

&gt; is there a way to defer my extension from running until all those arguments are resolved during supertype generation?
There is no way, annotation arguments resolution is the last phase before `BODY_RESOLVE` (see the link above)

hm, even if the annotation itself is a predicate of the supertype generator? It's annotation-based and I'm using the local type resolver in this scenario as well

related - I know IR in K2 does not allow modification of superinterfaces of user-defined sources. Would a declaration generated in FIR be modifiable though? That's what I'm currently doing this introspection for, but I could move it to IR if I can just accept the interface addition here and modify superinterfaces (on the generated FIR declaration) in IR later since they're not user-defined

&gt; hm, even if the annotation itself is a predicate of the supertype generator?
Yes. `COMPILER_REQUIRED_ANNOTATIONS` phase resolves just annotation types, not annotation arguments

&gt; I know IR in K2 does not allow modification of superinterfaces of user-defined sources
Not sure, if it's true. `IrClass.superTypes` is `var`, so you can replace the supertype list. But there would be a problem, that these changes woundn't be reflected in the metadata, because metadata generated based on FIR, not IR.
But there is a dirty hack: you can add new supertype both at IR and FIR at the same time. I cannot guarantee that it would work, but I don't see reasons why it shouldn't
```fun test(irClass: IrClass, newType: IrSimpleType) {
    irClass.superTypes += newType
    
    val classId = newType.classOrNull?.owner?.classId ?: return
    val arguments: List&lt;ConeTypeProjection&gt; = TODO() // convert in the same way as the type
    val coneType = classId.toLookupTag().constructClassType(arguments.toTypedArray())
    val typeRef = coneType.toFirResolvedTypeRef()
    
    val firClass = (irClass.metadata as? FirMetadataSource.Class)?.fir ?: return
    firClass.replaceSuperTypeRefs(firClass.superTypeRefs + typeRef)
}```

hmm, I was going off of this: <https://youtrack.jetbrains.com/issue/KT-67490>

though looking back, I guess that issue is more than the impl at the time was using descriptor APIs to replace them

I'll noodle a bit with what you suggested

hmm, I think that might be a dead end. While I could remove a superinterface, I'd also have to remove any inherited fake overrides I imagine. Feels like it might be a can of worms