Hi, I am migrating bunch of compiler plugins in ou...

# k2-adopters

[Ruslan Latypov]

Hi,
I am migrating bunch of compiler plugins in our company to the new K2 API. One of the plugins analyses type references and does some IO calls with results of the analysis. It is important for us to be able to use sources where type is defined (classpathes, files) and to limit IO calls to one per project.
In K1 we used AnalysisHandlerExtension.analysisCompleted stage for this purpose.
I have a K2 prototype of the plugin, it uses FirAdditionalCheckersExtension to obtain the data we need and to collect the data to an object in memory, it shares the object with backend and makes the IO call on IrGenerationExtension.generate.

How safe is it to share custom state between frontend and backend in k2? Do you have any suggestions on how we can make it frontend only?

[dmitriy.novozhilov]

At this moment there is no analogue of AnalysisHandlerExtension for K2, but we are working on it
So I'd say that your current approach is good workaround for now

[jbarr]

is there an update on the AnalysisHandlerExtension analogue or a YouTrack that we can subscribe to for updates?

[dmitriy.novozhilov]

There was FirAnalysisHandlerExtension added for K2 KAPT support, but it doesn't include an API you need
The closest ticket about smth similar to your case is KT-59555
Feel free to create an another one if existing doesn't fit your needs

[dmitriy.novozhilov]

I can't give any estimations on this
Right now all plugin API related tasks are postponed till 2.0 release, because our teams already overwhelmed with 2.0 release

[Ty Smith]

This might block buck/bazel users (where that's built in to the build system) from upgrading to k2 unless there's a different strategy that can be taken. There's a built in compiler plugin that uses it to do compiler avoidance.

[dmitriy.novozhilov]

I have a K2 prototype of the plugin, it uses FirAdditionalCheckersExtension to obtain the data we need and to collect the data to an object in memory, it shares the object with backend and makes the IO call on IrGenerationExtension.generate.

Actually this approach will work, if you collect all required information with frontend checkers
There is a guarantee that IrGenerationExtension is called only once per compilation

[dmitriy.novozhilov]

Sorry for long answer, I was on vacation

[Ty Smith]

@Ruslan Latypov Was this for the used-classes in Buck2? Do y'all have a plan to land that in the open-source repo. Would be nice to reference this approach if you've opened it.