I'm seeing some interesting behavior where KSP-gen...

# compiler

[Zac Sweers]

I'm seeing some interesting behavior where KSP-generated sources in iosSimulatorArm64Main are not visible in FIR during iosMain compilation but are visible during IR. Is there a way to force compilation on a more specific set of inputs to see them in FIR? Or perhaps I'm misunderstanding how this part of the pipeline works

[Zac Sweers]

sessions list is computed like this

[Youssef Shoaib [MOD]]

Why should iosSimulatorArm64Main be visible? iosMain doesn't depend on it. It appearing in IR is probably because it just happened to be available I think

[Zac Sweers]

No other FIR compilation appears to ever see those sources as best I can tell

[Zac Sweers]

It ends up being a blind spot to compiler plugins

[Zac Sweers]

CCing in @dmitriy.novozhilov, let me know if this is maybe worth filing an issue for

[dmitriy.novozhilov]

Could you please provide more details please?
At this point I don't entirely understand the problem.
Some additional info about relations between sourcesets would be also useful, as I'm not familiar with ios targets.

[Zac Sweers]

In the above example: HomePresenterFactory is a generated type (generated with KSP) into an iosSimulatorArm64Main source set. As best I understand, that’s a narrower source set under iosMain. However, it’s never seen by FIR plugins during compilation when compiling iosSimulatorArm64, as the narrowest FirSession it ever seems to get is iosMain. I encountered this while making this sample run on iOS and being surprised that it seemed like the metro plugin wasn’t running at all in iOS compilations: https://github.com/slackhq/circuit/pull/2184

[dmitriy.novozhilov]

But in the KMP compilation there are several sessions, one for each sourceset (during one platform compilation).
Do you observe all of them?

[Zac Sweers]

No, I only see these. It’s almost like it’s missing the iosSimulatorArm64 source set

[Zac Sweers]

But in IR it is able to see sources from that source set (if I breakpoint somewhere random and look up classes by their class id in the debugger)

[Zac Sweers]

closing the loop - dima and I talked more and the issue here is that the type that is generating supertypes is in iosMain but some of the supertypes it wants to see are only in iosSimulatorArm64, which does run in a later round of FIR. Basically, need to see if KSP can loosen its generation a bit here to allow for generating a common type to a hierarchical parent source set, otherwise anything processed here would need to be duplicated into all the iOS subtypes