With K2 mode in intelliJ does the Kotlin compiler ...

# k2-adopters

[Gat Tag]

With K2 mode in intelliJ does the Kotlin compiler now inform the ide of related symbols for things like refactoring, highlighting, and find usages. Or is that part of the language understanding still handled by the intelliJ Kotlin plugin?

[dmitriy.novozhilov]

Both K1 and K2 IDE plugins use Kotlin compiler under the hood to receive the resolve information (which call is resolved to which function and so on)
The difference is what exact compiler they are using

There was never any special resolution logic in the Kotlin IDE plugins

[dmitriy.novozhilov]

Actually, Kotlin is the only language for which there is no need to implement resolution logic in the intellij plugin (at least AFAIK)

[Gat Tag]

Would that mean that I could potentially associate a source declared property with a parameter of a function I generate in a Kotlin compiler plugin and the ide would understand that and support refactorings for it?

[dmitriy.novozhilov]

Could you please elaborate on this?
I didn't get the case

[Gat Tag]

If user defines the following:

interface Foo<V>{
   val foo: List<V>
 }

interface Bar<T>: Foo<Set<T>>{
   val bar: T
   val tan: Int
 }

Compiler plugin generates the invokes

interface Foo<V>{
   companion object{
     operator fun <V> invoke(foo: List<V>): Foo<V> = TODO()
   }
   val foo: List<V>
 }
 
 interface Bar<T>: Foo<Set<T>>{
   companion object{
     operator fun <T> invoke(bar: T, tan: Int, foo: List<Set<T>>): Bar<V> = TODO()
   }
   val bar: T
   val tan: Int
 }

If someone called the invoke using named arguments, and then someone else refactored the property that would cause a refactoring to the parameter?

[Gat Tag]

Because currently my plugin can generate this, but the IDE doesn't understand the two symbols are linked

[Gat Tag]

By plugin I mean K2 compiler plugin

[dmitriy.novozhilov]

The invoke function will be regenerated, but its usages most likely won't be updated
But the case is very interesting, thank you
I think it potentially can be done in the future
cc @Roman Golyshev

[Gat Tag]

Yeah I see it live regenerated in intelliJ as I add new properties to the interfaces, but I don't know how I would associate the two elements in FIR. From your last message am I to assume that there currently is not a way to associate them? I thought maybe there was a chance because of val declarations in a class constructor declaration

[dmitriy.novozhilov]

This "assosiation" as you called it (I don't know what term IDE guys use for it) is handled on the IDE level
Compiler doesn't know about any refactorings, as it's not intended for the compiler to modify the code

[Gat Tag]

Yeah I'm not sure what to call it either, but this is where the question that started the thread came from. Does the compiler inform the ide that the name of a parameter declaration of a function is related to the use of that name in a named argument in a call to the same function, or is that kind of understanding from the ide?

[Gat Tag]

Please let me know if I'm not making sense

[dmitriy.novozhilov]

Does the compiler inform the ide that the name of a parameter declaration of a function is related to the use of that name in a named argument in a call to the same function

It all comes from IDE. I definitely know about following things, which are checked during refactorings (but there are definitely more):
• overloads of the function in case of changing the function signature
• properties/parameters with the specific type in case of renaming/moving some class
The connection you are asking for is kinda new one, as it happens only with compiler plugins (which are poorly supported sadly)
It definitely makes sense, and it's worth to create a feature request for it

[Gat Tag]

Okay good to know. If I'm to create a feature request, which project under YouTrack should it be

[dmitriy.novozhilov]

It's KTIJ (Kotlin Intellij IDEA plugin)

[Gat Tag]

Okay thanks

[Gat Tag]

Also you wouldn't happen to know if a compiler plugin can generate kdocs that ide understands in its completion menu?

[Roman Golyshev]

Unfortunately, such kind of refactoring dependencies is not trivial. Especially because the mapping between real and generated declarations can be arbitrary complex

You can generate fooBar parameter from barFoo name somewhere else, and figuring out the correct rename is impossible at this point

Please, create an issue with your request on our YouTrack (KTIJ project), and we’ll see if there’s something that can be done about it 🙏

[Roman Golyshev]

if a compiler plugin can generate kdocs that ide understands in its completion menu

Could you please elaborate a little bit here? Do you want to be able to generate KDoc for existing declarations, or for the generated ones?

[Gat Tag]

The generated ones, I want to bring the docs of the properties to the generated function

[Gat Tag]

For use in the intelliJ completion menu

[Gat Tag]

I understand that there isn't a real declaration, but I'm hoping that the info is provided by the complier and not the IDE

[Roman Golyshev]

Since currently the API for the declarations generation revolves around FIR, and FIR does not know anything about KDocs by its nature, it is impossible to do that

But if FIR had some way to carry some additional information (a String with a KDoc content, for example) via some attribute, I guess that it would certainly be possible to handle this attribute by Analysis API and then to provide it in the IDE

@dmitriy.novozhilov WDYT?

[dmitriy.novozhilov]

Yeah, it completely feasible

[Gat Tag]

And thank you both for taking the time to respond to me 🙂

[Gat Tag]

Would that be another feature request?

[dmitriy.novozhilov]

Yes. This time in KT project

[Gat Tag]

Okay, thank you!

[Roman Golyshev]

Gregory, if you have created or plan to create any YT tickets, please re-post them here so that they are seen in the thread. Thanks!

[Gat Tag]

I'm planning on creating the tickets in about 2 hours. I will also post the links in here when I have

[Roman Golyshev]

There is a ticket for KDocs already:

https://youtrack.jetbrains.com/issue/KT-61930