Hi folks! I'm trying to find the correct PSI classes to use in order to get a `KtNamedFunction` from...

# compiler

[Claudiu-Vlad Ursache]

Hi folks! I'm trying to find the correct PSI classes to use in order to get a KtNamedFunction from a KtCallExpression, or something similar. Is that possible at all, maybe with a Resolver or something? I followed the instructions in the documentation about getReferences(), but I get a null value for a very simple example like this one:

fun add(x: Int, y: Int): Int {
    return x + y
}

fun main(args : Array<String>) {
    println(add(1 + 2, 3))   // <- How do I get from the PSI node of add to the PSI node of add's declaration
}

[Youssef Shoaib [MOD]]

Yeahhh I ran into that same issue. getReferences() only works in the context of an IDE plugin, and it has no value when dealing with the Kotlin Frontend. You can see an example of how to do it over at my repo (the code might not make too much sense though) but the quick TL;DR is that you need an AnalysisHandlerExtension and then in its analysisCompleted function use the bindingTrace.bindingContext to call KtCallElement.getResolvedCall(BindingContext) and that'll simply get you a ResolvedCall object that has a resultingDescriptor property that then simply has all the info and data about the function that the call element is referring to.

(Also if you do check the repo make sure to check out and possibly vote for KT-44530 because the whole repo is a POC of that issue. The TL;DR of that issue is that the Kotlin compiler currently can't, but should, be able to inline some lambda returning functions. if that issue does get implemented, that can result in things as crazy as actual zero-overhead structs being possible idiomatically)

[Youssef Shoaib [MOD]]

Shoot at me with any other frontend or IR questions if needed :)
My knowledge isn't as extensive as the Arrow Meta team for example, but I still know my war around some things and the memory of knowing absolutely nothing about how compiler plugins work is still fresh in my mind

[Claudiu-Vlad Ursache]

That's super nice of you @Youssef Shoaib [MOD], I'll give it a try and definitely take you up on the offer

[Claudiu-Vlad Ursache]

Oh, and the example file you wrote, that's not bytecode dependent, right?

[Claudiu-Vlad Ursache]

That is, the call resolution works on source code info alone

[Youssef Shoaib [MOD]]

Not at all byte-code related. It just deals with the result of the compiler front end analysing the code yes

[Claudiu-Vlad Ursache]

OK cool, exactly what I need, thanks

[Youssef Shoaib [MOD]]

However technically it is "bytecode dependent" in that for example if you reference a Java function then of course it'll be referring to that. Oh and also careful because AnalysisHandlers are currently Kotlin JVM only. The plan is that with the new Frontend IR there will be some unified API that has better semantics than AnalysisHandlers to deal with code analysis but of course currently the FIR is not ready for extensions like at all

[Claudiu-Vlad Ursache]

Alright, appreciate the explanation