Also all `owner` property in the IR nodes are now null whereas before they always contained the poin...

# compiler

[raulraja]

Also all owner property in the IR nodes are now null whereas before they always contained the pointer to the symbol

[shikasd]

Do you check owner on the files from the same or different module?
It was working for me when I last checked

[shikasd]

If it is from different module, there could be some issues with serialization/deserialization if it is from klib

[raulraja]

The public extension point changed from a file to a module fragment that has a list of files

[raulraja]

The transform API methods are also in fragment and it recursively calls all the files

[raulraja]

I put a debug point and it seems to fail here:

private fun StringBuilder.renderAsAnnotation(irAnnotation: IrConstructorCall) {
        val annotationClassName = try {
            irAnnotation.symbol.owner.parentAsClass.name.asString()
        } catch (e: Exception) {
            "<unbound>"
        }

[raulraja]

@shikasd it is indeed that all symbols from third party dependencies are unbound except those of the local module fragment

[raulraja]

When it goes through that code it throws:

java.lang.IllegalStateException: Symbol for public constructor Refinement(predicate: kotlin.String) defined in arrow.Refinement[DeserializedClassConstructorDescriptor@24dcf5a1] is unbound

[raulraja]

Refinement is declared in an already compiled jar this test depends on.

[shikasd]

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 :)

[shikasd]

Maybe kotlinx-serialization or android extensions solved it before?

[raulraja]

concretelly all irElement.symbol.owner from jars deps are null and it always blows up there

[raniejade]

I have the same issue and filed a ticket a while ago: https://youtrack.jetbrains.com/issue/KT-37482

[raulraja]

thanks @raniejade

[raulraja]

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?

[raniejade]

Not aware of any workaround, unfortunately.

[raulraja]

related https://youtrack.jetbrains.com/issue/KT-37255 and https://github.com/JetBrains/kotlin/pull/3186

[shikasd]

@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.

[raniejade]

@raulraja have you found any workaround? I'm effectively blocked from upgrading spek to 1.3.70 😞

[raulraja]

@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.

[raniejade]

@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.