I've noticed while debugging an issue in a `FirSup...

# compiler

[Zac Sweers]

I've noticed while debugging an issue in a FirSupertypeGenerationExtension that session.predicateBasedProvider.getSymbolsByPredicate() does not find symbols in commonMain sources when it's running on a class defined in a jvmMain source set.

If I hop in the debugger and manually look up an expected matching symbol, it is present and session.predicateBasedProvider.matches(predicate, symbol) does return true. What I noticed is that two different `FirSession`s appear during the compilation, I'm guessing one for commonMain and then a different one for jvmMain. Their internal predicatedBasedProvider caches are limited to their own sources though. Is there any way to match these symbols from platform-specific FIR extensions?

[dmitriy.novozhilov]

You can use the following to get access to sessions of dependent MPP modules:

val moduleData = session.moduleData
val commonSessions = moduleData.allDependsOnDependencies.map { it.session }

But in general it makes sense to carefully think why do you depend on something from the other module during generation of something with your plugin. For example, how it would work for metadata compilation of the common modules?

[Zac Sweers]

Can you unpack that last bit more for me?

[dmitriy.novozhilov]

There are compileKotlinPlatform tasks in Gradle (like compileKotlinJvm) which compile all MPP sourcesets at once and produce the resulting binaries, and also compileKotlinCommonMetadata tasks, which compile all non-leaf modules independently to metadata klib artifacts
So if you have, for example, common -> jvmAndJs -> jvm structure, sources of jvmAndJs would be compiled to metadata independently, and declarations from common will be passed as plain binary metadata dependencies.

In this situation if you want to generate something in non-leaf module, you won't have access to all sources, just one sourcest

[Zac Sweers]

Ahh I see what you mean. Thats good to know. Thanks for the details!

[dmitriy.novozhilov]

There is one more important things to know regarding these metadata compilations.
Right now metadata artifacts are effectively used only in the IDE, but we are planning to change the compilation scheme in a way that common sourcesets will see the common klibs as dependencies instead of the platform ones

[dmitriy.novozhilov]

Some context why it's needed:

// lib-common
fun foo(x: Int = 1) {} // (1)
// lib-jvm
fun foo() {} // (2)

// app-common
fun test() {
    foo()
}

In this example the call foo() is resolved to
• (1) during metadata compilation of app-common
• (2) during jvm compilation of app
• (1) in the IDE
After this change everything will be resolved to (1)