Hey, as mentioned above, in current version of com...

# compiler

[shikasd]

Hey, as mentioned above, in current version of compiler (1.4-M3) many links to descriptors from IR have been deprecated.
I am curious, what is a recommended way of passing data from frontend to backend in the current implementation?
Before, I was using BindingContext with custom slices as a source of such information, but it was mostly relying on certain descriptors being in place.
As I see, I still can do same kind of manipulations with them, but as they are deprecated, is there any other means achieve similar results?

[Roman Artemev [JB]]

Hi. Could you please describe your case a bit more?

[shikasd]

Sure, the case is pretty similar to what compose does to an extent.
I have some function calls that I want to intercept and wrap with some conditions on the backend
The thing is that I am already running validations using CallChecker api, to ensure that context of a call is correct.
There I find required KtCallExpressions / function descriptors, and then on backend I traverse IR tree to find those calls and wrap them with required instructions.

[Roman Artemev [JB]]

So am I correct that you need some way to wrap your special declaration descriptor into something what backend can understand?

[shikasd]

Currently I am not wrapping it, but just using collective slice and binding context to check if function call needs special ir transforms
My confusion lies in the fact that descriptors are getting deprecated to use from IR, so it is not quite clear how we can connect those two otherwise 🙂

[Roman Artemev [JB]]

Sorry, it’s still unclear for me what kind of information do you lack in IR so you have to use binding context. As I can see IR contains enough information to perform any analysis or transformation.

Binding context is internal front end data and it shouldn’t be accessed from IR.

[shikasd]

You are correct that IR has enough information on its own to run analysis in most of the cases.
But then this work has to be done twice on both frontend and backend. On frontend - at least to report logical errors, on backend - to actually find elements to transform.
For now, I keep this info associated with descriptor, so I don't need to check into signature of the function call and parameters I am transforming 🙂

[shikasd]

I think serialization plugin does something similar.
They use binding context to pass properties that should be serialized in class to IR transforms and create their serializers based on this data.

[PHondogo]

I just wonder, why not to make this in only IR phase?

[Roman Artemev [JB]]

Yes, you are right that ktx.serialization does similar thing but I’m personally considering it as a tech debt.

Also I agree that there is a need for some way to pass information from FE to IR. We are working on in. Actually today we had an internal discussion about this particular issue.

Is that analysis you do is hard to implement on top of IR till we haven’t introduce additional API?

@PHondogo If you want to make plugin effects visible in IDE it should be done in front end.

[shikasd]

I think I can reimplement it, as it is easier with new referenceFunction apis
Just was curious how it is supposed to be working out now 🙂

[shikasd]

Thanks!

[shikasd]

@PHondogo I keep the analysis hooks (checkers in particular) to allow for better error reporting on particular PsiElement.