Sorry for the spam, I just figured it would be bes...

# compiler

[Caleb B]

Sorry for the spam, I just figured it would be best to keep different issues to different threads.

I'm glad I tested my plugin in my own IDE, because now I'm getting this error:

java.lang.NoSuchMethodError: org.jetbrains.kotlin.fir.symbols.impl.FirValueParameterSymbol: method 'void <init>()' not found

The stacktrace points to the FirValueParameterSymbol() instantiation in the attached image.

Apparently that class doesn't have a default constructor in whatever compiler version IJ's using, but I can't tell what version that is. My test project is definitely built against the exact same kotlin-jvm version I'm building the plugin against, since I'm using the same version ref for both.

Does anyone know how to fix this?

[Youssef Shoaib [MOD]]

Separate threads is absolutely the way to go! It makes the discussion much easier to follow. If you're really worried, you can always put details in thread so that readers of the channel only see a single line message.
Now lemme read what the issue is...

[Youssef Shoaib [MOD]]

So a big part of why plugins aren't loaded into IDE by default is because the IDE bundles dev versions of Kotlin (i.e. they're cut right from the repository). Hence, the version of Kotlin in IDE is unlikely to correspond to any "normal" version that you might test against.
To see your IDE Kotlin version (at least on macOS), click on IntelliJ Idea in the top left corner, and press "About IntelliJ Idea", then look at the Kotlin Analyzer version.
Now, what I'd suggest you try and do is find a reasonable "normal" version that's close to, or above, that IDE version, and build your plugin based on that. You should then be able to figure out how to replace that call.
If you want to go really overkill, you can add a layer of indirection and call APIs based on the Kotlin compiler version, which is what Metro does.
Personally, I'd just go with changing the Kotlin version of the plugin for now, or updating IntelliJ.

[Caleb B]

Does Metro happen to release said abstraction layer anywhere?
EDIT: Nevermind, the answer is no. I should probably use my eyes more often.
> This collection of artifacts is not published and is instead shaded into Metro's compiler plugin.

[Caleb B]

A better question would be: have you guys considered working with Metro to build off its ad-hoc compatibility layer into a sort of intermediate stable-API while you work on the final one?

[Caleb B]

Cause it seems like half the work's done for you

[Youssef Shoaib [MOD]]

I think that's partially a goal of KT-49508. Metro's compatibility layer is likely very specific to the APIs that it uses (in fact, looking at it now, there's 13 APIs that I can see), so I'm not sure how useful it'd be. You can, of course, just copy their compatibility code and use it yourself. It might even be doable by keeping a git submodule fork that simply adds local publishing or something like that.
(Btw, I'm not on the Kotlin team, nor affiliated with JetBrains in any way; MOD just means I'm a moderator, which is just a hall monitor with no powers, really)

[Caleb B]

Ah, makes sense. On both fronts.

[Caleb B]

Thanks for the help btw

[Caleb B]

Wow ok, so it turns out that both 2.2.20 and 2.3.0 have FirValueParameterSymbol take no args, but specifically 2.2.20-ij252-24 has an argument

[Caleb B]

that's so cool and hype, why did they do that

[Caleb B]

especially since it immediately gets overwritten when it's bound to the fir

[Caleb B]

Oh god does this mean IJ's k2 version is on a different branch?

[Youssef Shoaib [MOD]]

More like intermediate commits, I believe. I'd have to hunt down the commit, but maybe it was just a "dumb" change that was reverted soon thereafter