Kotlin compiler plugin generate synthetic `compani...

# compiler

[turansky]

Kotlin compiler plugin generate synthetic companion object = I need assotiated IDEA plugin for comfort work with this companion object ?

[raulraja]

Yes you need an IDEA plugin to show synthetic descriptors non red lined. Which in my opinion makes no sense because IDEA could at least fetch synth descriptors automatically from the output class directory like Arrow Meta for all its subplugins.

[raulraja]

This is have been a long issue in other communities too. Most Scala libs that relied on Macros were not supported in IDEA because they all have to provide their own plugins and synth descriptors and nobody bothers to do that. On the other hand this became such an issue that the Scala Plugin for IDEA itself bundles the synth descriptors for known third party libs like cats or simulacrum.

[raulraja]

IDEA could solve all this for al langs in the same way without requiring people to write manual synth descriptors for their plugins. In general compiler plugins that generate synth declaration should not need an IDEA plugin. Synth declarations can be introspected or added as metadata in the parents where they are declared for tooling automatically to recognize it. This could be implemented in the Kotlin plugin perhaps or as part of the IDEA Open API native lang support

[Hanno]

Stumbled around the exact same problem also already, very strange indeed. Just ooc, does anyone know how eclipse handles this? Does it use the class files directly?

[turansky]

@raulraja Do you need/have IDEA plugin for Λrrow?

[raulraja]

Arrow Meta comes with a bundled IDEA plugin that will autoinstall itself

[raulraja]

if you add the gradle dependency and detects you are in IDEA

[turansky]

Gradle plugin will install it?

[raulraja]

Yes we need this plugin to do what I was hoping IDEA would do automatically which is auto-recognize the synth declarations but we are using for much more. Since we are force to have we are taking advantage of the situation to bring better visual and aids of the FP patterns in Arrow right on the Editor

[raulraja]

That is one of the biggest changes we are working on 2020 in Arrow and Arrow Meta.

[raulraja]

In whatever case the idea scenario is that if IDEA detects the user module includes a library that contains an autorunnable IDEA plugin it should at least prompt the user to activate the plugin and that’s it

[raulraja]

that whole marketplace search of plugin hidden in the settings is unfair to community plugins which are in clear disadvantage in contrast to autobundled plugins like the ones in AS and IDEA

[raulraja]

IDEA could auto activate upon user permission gradle declared plugins or any plugins declared in the sources in the local project and everyone would be happy.

[raulraja]

Then Arrow all it had to do is declare a manifest or something where it tells IDEA where its compiled plugin is so it can activate it and bring its users the best experience.

[raulraja]

I’ll be happy to do all this work myself with help from the Arrow Community and 47 to make it happen that IDEA plugins do not require manual installation if there is a will by the product owners of that part. Not sure who they are and what the reasons to keep this gate around IDEA plugins is.

Any Gradle plugin can already access the user filesystem so it’s not like there are security concerns, you can auto install plugins copying them to the user folder too but I think that is probably not a recommended way and forces lib authors to hack their way through.

[turansky]

Is there related ticket on https://youtrack.jetbrains.com/?

[turansky]

@raulraja Do you need synchronization between Gradle & IDEA plugins?

Gradle Arrow 1.0 need IDEA Arrow 1.0?
Gradle Arrow 2.0 need IDEA Arrow 2.0?

[raulraja]

Not necesarilly since the IDEA plugin part is mostly the part in the Open API which does not change much but we are gonna sync arrow and meta with the compiler and lang

[raulraja]

Meta is already synced and we find out when a new version of the lang is gonna break it

[raulraja]

But the Meta API depends on the compiler internals so that part we need to make sure there is always an arrow version for an equivalent std lib and a meta version for the lang.

[raulraja]

Essentially we are gonna replace our release cycle with the one of the lang.

[raulraja]

I don’t think there is a ticket for it. I discussed this with many people and nobody seems to understand why IDEA plugins require manual menu click through intervention for the user but again, there may be a reason, as a lib author I sure wish it was automatic.

[turansky]

We need a ticket 🙂

[raulraja]

Yes

[turansky]

https://youtrack.jetbrains.com/issue/IDEA-227487

[raulraja]

Thanks you @turansky, I’ll link this conversation for context.

[turansky]

Performance - main reason from IntelliJ team, which I know.
IDEA plugin don’t need compilation.

[raulraja]

If a Project declared a dependency on an IDEA plugin via Gradle or maven with some special qualifier IDEA can just load it without any performance penalties. It's already compiled binaries

[raulraja]

Or via manifest.xml

[raulraja]

Whatever suits the open API needs. I think in general lib authors want their plugins autodetected vs the marketplace search

[raulraja]

Even if it requires a restart it would be progress compared to the current UX