Is there a way to remove/replace existing methods ...

# compiler

[Ahmed Mourad]

Is there a way to remove/replace existing methods with a compiler plugin?

[Foso]

Yes, take a look at Arrow Meta https://meta.arrow-kt.io/

[Ahmed Mourad]

@Foso Problem is the plugin is already implemented in primitives, I'm definitely migrating to Arrow Meta, but not yet.

[dmitriy.novozhilov]

@Ahmed Mourad using standard compiler API you can't remove function from resolve, but can change some method's body using IrGenerationExtension for backend IR. You can also change signature of function, but if you do then you need also change all call sites

Can you share usecase when it's needed to remove some user defined function?

[Ahmed Mourad]

@dmitriy.novozhilov

There are two different use cases,

First use case is removing the data class generated copy method, current implementation involves removing it from the mutable collection in generateSyntheticMethods so the user can't reference it and so it gets removed in the optimization stage.

However it's not optimal and does have its corner cases so I want to remove it entirely in favor of a more robust implementation.

The second use case is I want to modify the visibility of some methods generated by Google's safe-args plugin, while also adding other methods but that's way off-topic i guess.

[dmitriy.novozhilov]

Thank you
1. auto generated copy and componentN in data classes is a known language design problem, but we haven't any solution for it yet (it's not obvious how user should tell compiler if he wants those methods or not and also there is a compatibility problem)
2. I suppose for this case your method with SyntheticResolveExtension should also work. Am I right?

[dmitriy.novozhilov]

We want to add separate extension point for changing status (visibility/modality/modifiers) for declaration in new frontend and, for now, we don't see anything that block us from adding it

[Ahmed Mourad]

@dmitriy.novozhilov

1- Yup, I found the YouTrack issue a while ago while facing the same problem and I thought I would provide a custom solution for it util it's fixed in a breaking release or something.

Currently I'm doing it by having the user annotate their classes with @NoCopy but if the problem is to be solved at a language level, I suppose you need a more elegant solution than method-specific annotations.

I was also looking at the componentN problem ever since Jake Wharton brought it up in his talk but so far all solutions I found are complicated to implement and would break existing code.

Regarding the copy method, is it possible to remove it with a compiler plugin? or do i have to stick with my implementation?


2- It works for changing visibility to anything but internal , changing to internal causes problems due to missing synthetic methods.

[Ahmed Mourad]

New extension points would be really cool imo, we're also supposed to get official docs for compiler plugins at some point in 1.4, right?

[Drew Hamilton]

For (1) you could try my (JVM-only) compiler plugin for "data" classes with no copy/componentN if it meets your needs: https://github.com/drewhamilton/ExtraCare

[dmitriy.novozhilov]

we're also supposed to get official docs for compiler plugins at some point in 1.4, right?

Unfortunately no, current compiler API remains unstable and undocumented. We are focused on developing new consistent API for plugins that will be implemented in new compiler frontend, but it's unknown when it will be released (we hope that there will be some beta in next spring, but there are no guaranties)

[Ahmed Mourad]

@dmitriy.novozhilov That's good enough for me 🙂

Thanks for your time.

[Ahmed Mourad]

@Drew Hamilton Great job you did there man!

Unfortunately though, my plugin is already implemented and I'm already using it, I'm just trimming the edges at this point.