After migrating my compiler plugin to use `Compile...

# compiler

[damian]

After migrating my compiler plugin to use CompilerPluginRegistrar in Kotlin 1.8.10, I ran across a strange issue that I can't seem to reproduce in tests, and it only seems to happen in certain places in my codebase.

My plugin alters the base classes of some classes, but I found that some classes have multiple different instances of `IrClass`/`IrClassSymbol`/etc in memory - that is to say, there are multiple objects referring to the same underlying class. For example, the superclass of class A (which I arrive at from a visitor) should be the same as the superclass of class B (which I retrieve through referenceClass), but these two are actually different objects (though poking around in the debugger does show that they're basically the same except for the source parameter - one has NO_SOURCE, and one actually has it).

This is causing problems because there are various checks and assertions elsewhere the compiler that check whether one class is a subclass of other, which have started failing (again, only when this happens, which is /sometimes/) because the underlying check for class hierarchy uses reference equality. In my case there are assertion failures in the synthetic accessor lowering (which seems to only be trying to generate synthetic accessors in the first place because it finds that a calling class is not a subclass of a member's declaring class, which is not true).

Is anyone else aware of such a problem? I had a really hard time searching for this in a way that doesn't bring up other unrelated problems.

[Youssef Shoaib [MOD]]

It could be easier, and more user-transparent, to edit those base class lists in FIR. I think that should likely have better support (ironically) since FIR has an API specifically for that

[damian]

Ah, great to know, thanks! I have to enable K2 for that right? We haven't tried it out yet, but I will definitely look into it once we look into it.

[shikasd]

I wonder if something else transforms your class on top of your plugin, e.g. some other compiler plugin that changes something in the class instance

[dmitriy.novozhilov]

I want to highlight that this issue can not be caused just by migration to CompilerPluginRegistrar
CompilerPluginRegistrar and ComponentRegistrar are purely identical. The only difference between them is that the first one hides Project from the plugin. Underneath they do purely the same

[damian]

That makes sense to me - perhaps something else is at play. I only encountered this problem after migrating to CompilerPluginRegistrar, but perhaps as Andrei mentioned this resulted in compiler plugins running in a different order? I am using KSP as well, and the difference in the two instances is between a class from KSP and one not from KSP, so maybe that's where it's coming from...

[dmitriy.novozhilov]

Hm, it's very interesting
Officially there is no stable order of compiler plugins, but effectively they are applied in the order in which plugins were passed to CLI arguments
At the same time KSP is more like separate tool, which works before real compilation (and uses it's own compiler under the hood)
Honestly, I have no idea how KSP handles compiler plugins (moreover I surprised that it somehow invokes IR plugins, since it's enough to use just frontend information for KSP needs), so it's better to ask about it KSP devs in #ksp

[damian]

Yeah I figured as much - I'm not actually running the compiler plugin within KSP's compilation, only the main compilation, so it seems like that's probably not the issue