Also all `owner` property in the IR nodes are now ...
# compiler
r
Also all
owner
property in the IR nodes are now null whereas before they always contained the pointer to the
symbol
s
Do you check owner on the files from the same or different module? It was working for me when I last checked
If it is from different module, there could be some issues with serialization/deserialization if it is from klib
r
The public extension point changed from a file to a module fragment that has a list of files
The transform API methods are also in fragment and it recursively calls all the files
I put a debug point and it seems to fail here:
Copy code
private fun StringBuilder.renderAsAnnotation(irAnnotation: IrConstructorCall) {
        val annotationClassName = try {
            irAnnotation.symbol.owner.parentAsClass.name.asString()
        } catch (e: Exception) {
            "<unbound>"
        }
@shikasd it is indeed that all symbols from third party dependencies are unbound except those of the local module fragment
When it goes through that code it throws:
Copy code
java.lang.IllegalStateException: Symbol for public constructor Refinement(predicate: kotlin.String) defined in arrow.Refinement[DeserializedClassConstructorDescriptor@24dcf5a1] is unbound
Refinement
is declared in an already compiled jar this test depends on.
s
Yep, that's what I meant, had the same problem Not sure how to act in the jar case, I was looking into the problem on native only :)
Maybe kotlinx-serialization or android extensions solved it before?
r
concretelly all
irElement.symbol.owner
from jars deps are null and it always blows up there
r
I have the same issue and filed a ticket a while ago: https://youtrack.jetbrains.com/issue/KT-37482
r
thanks @raniejade
Do you know if there is any kind of workaround or is this saying that all IR based plugins are broken in 1.3.7?
r
Not aware of any workaround, unfortunately.
👍 1
s
@raulraja It seems like you can try to construct an instance of
IrClass
with an unbound symbol.
IrClassImpl
, for example has
symbol.bind(this)
call inside its constructor. However, I am not sure how this will affect remaining stages of codegen.
r
@raulraja have you found any workaround? I'm effectively blocked from upgrading spek to
1.3.70
😞
r
@raniejade no, I talked to @udalov and it seems the plugins get called now before the symbols are bound and this breaks IR plugins in 1.3.7. We had to revert to 1.6.31 but as far as I understood it there is no work around for it. @udalov may have more info but he mentioned he'd make a note so they consider it in the upcoming patch releases for 1.3.7. This makes me think we need a community build for compiler plugins because otherwise the compiler is unaware when it breaks IR in each release. But again these are undocumented and not officially supported APIs.
😞 2
r
@udalov can you suggest any alternatives? I just want to check if a class is a subclass of
Spek
and generate some code that is used for discovering tests. Tried using
CollectAdditionalSourcesExtension
but I don't have access to classes contributed by external modules.