Funny situation. Just finished writing a compiler ...

# random

[Gleb Minaev]

Funny situation. Just finished writing a compiler plugin (that is similar to Wither compiler plugin) for my own needs. But, because of it, order of declarations in an object affects resolution of a function's body that uses the object 🙂 (See attach.)

I am not going to use the plugin like that! But it will be cool if there will be a analogue of FirExpressionResolutionExtension that adds contexts instead of receivers.

[Youssef Shoaib [MOD]]

I should probably update Wither, and maybe take on some of the feature requests...
I think you can get the compiler to give you an ambiguity error here! I have this in wither in the form of with(foo, bar, baz) being considered in the same "group" (similar to context parameters), so ambiguity errors arise automagically.
It could be the case that this only triggers for contextual calls, though, so maybe it wouldn't error in your case, sadly
It's been a while, but I believe the trick is to have all of the new receivers have the same containingDeclarationSymbol like I've done here (I just create a fake one per with call, so ambiguity happens within a with, but multiple `with`'s can override each other).

Btw, feel free to reach out (mention, DM, etc) with any compiler plugin questions! I'm still obsessed with them

[Youssef Shoaib [MOD]]

it will be cool if there will be a analogue of FirExpressionResolutionExtension that adds contexts instead of receivers.

Man, I wish! My understanding is that FirExpressionResolutionExtension is specifically for DataFrame, so it's tailored to its needs. They generate a local class (in a FirFunctionCallRefinementExtension), which has members that give you type-safe access to dataframe columns. They don't really have a use for contexts, so it probably won't be added.
What I've thought about is some hacky business to get access to the underlying BodyResolveContext, and add whatever receivers I want on it and such. The consumer of addNewImplictReceivers just iterates over it and calls BodyResolveContext.addReceiver

In fact, the sessionHolder passed to addNewImplicitReceivers just so happens to be a BodyResolveTransformerComponents, which has context: BodyResolveContext.
Do with that information what you will...

[Gleb Minaev]

Thank you for your advises! 🙂

> It's been a while, but I believe the trick is to have all of the new receivers have the same containingDeclarationSymbol like I've done here (I just create a fake one per with call, so ambiguity happens within a with, but multiple `with`'s can override each other).
Actually, Wither is my inspiration and source of ideas for the compiler plugin. So you can see similar things from Wither in it. In particular, I used this trick as well. But each next receiver just overrides the previous one for some reason... So I think it really works only for contexts (like for any regular with(receiver1) { with(receiver2) { ... } } block). And I don't like the need to write this@myFunctionName instead of usual this because this captures the last such receiver instead of receiver of my function.

> Btw, feel free to reach out (mention, DM, etc) with any compiler plugin questions! I'm still obsessed with them
Thank you! ❤️ I'll message you when I'll be stuck in the future.

Actually, I have an idea of a strange compiler plugin that will help in checking parallel data structures like Lincheck does model checking (the only difference will be that Lincheck modifies JVM bytecode while this plugin in my fantasy modifies platform-independent FIR and IR). Just for fun (and maybe my master's paper). If I will be doing that, I'll have a lot of questions 🙂

> They don't really have a use for contexts, so it probably won't be added.
It's sad. 😥 But I understand.

> Do with that information what you will...
Well, it's very interesting! I'll look into it and message if I find something interesting as well.