https://kotlinlang.org logo
#compiler
Title
# compiler
t

Tóth István Zoltán

03/27/2024, 11:55 AM
I would like to generate a class for top-level functions that match a given criteria. I'm thinking about using
FirDeclarationGenerationExtension.getTopLevelClassIds
to return with the ids to generate. The question is how should I find the functions declared in the current module?
j

Javier

03/27/2024, 12:05 PM
If you don’t know the
FqName
I think you can only use annotations.
session.symbolProvider
couldn’t be used in that method if I remember correctly.
So you are forced to use predicated one (annotations) or hardcoded values you already know
t

Tóth István Zoltán

03/27/2024, 12:07 PM
Thx, I try to avoid annotations when possible. The predicate based provider does it somehow, so there is a possibility. I actually have code that works for classes without annotations (it checks what the class extends). I would like to have the same for functions.
j

Javier

03/27/2024, 12:08 PM
AFAIK in generation the predicated provider only works with annotations. It is more powerful on checkers.
t

Tóth István Zoltán

03/27/2024, 12:09 PM
Yes, that's my info as well (I mean annotation only predicates). But I plan to avoid the predicate based provider. And just go over the top level functions and decide if I want the class or not.
But I don't know how to get all the top level functions of the package. For classes the compiler calls `getNestedClassifiersNames`that's what I need for top level functions.
j

Javier

03/27/2024, 12:10 PM
That is what is weird to me, I wouldn’t expect you get it working for classes
t

Tóth István Zoltán

03/27/2024, 12:11 PM
No, I mean I need something similar for the top-level functions.
For classes it works well.
j

Javier

03/27/2024, 12:12 PM
Yeah, I understand, what I mean, is the opposite, you should not be able to get that in classes, and you are getting it
@dmitriy.novozhilov is that behavior expected?
t

Tóth István Zoltán

03/27/2024, 12:14 PM
Why not? I think that's the whole point of FirDeclarationGenerationExtension. I mean what I do is to add declarations + companion objects to classes which extend a specific base class.
j

Javier

03/27/2024, 12:16 PM
AFAIK the only way we should be able to use the generation extension is only by annotations, and you are being able to do that without an annotation and without knowing the the
FqName
before hand of those classes.
I don’t know if your use case is an exception or a bug/leak
t

Tóth István Zoltán

03/27/2024, 12:18 PM
I use the
fir
data from the session. Which is actually internal. But I decided to use it as I really, really hate annotations. They should not be used for everything, but they are usually used for almost everything.
d

dmitriy.novozhilov

03/27/2024, 12:19 PM
But I don't know how to get all the top level functions of the package
You can't
j

Javier

03/27/2024, 12:19 PM
Have you tested your plugin in an IDE?
Take care, some things work in tests but later in the IDE they do not exist
For example getting data from other modules was working in tests and it was totally null in the IDE
t

Tóth István Zoltán

03/27/2024, 12:20 PM
Yes, but as 2024.1 EAP does not support multiplatform it is basically useless to test it now. Also, the generated code won't be visible from the IDE.
d

dmitriy.novozhilov

03/27/2024, 12:21 PM
Also, the generated code won't be visible from the IDE.
In this case you need to generate it in IR, not in FIR
t

Tóth István Zoltán

03/27/2024, 12:22 PM
I do it with IR atmn. I was thinking being good and doing it with FIR. 😄 But I'll just skip it then.
Btw, is there a particular reason why can't we see the FIR tree from the generation extension? I don't want modify, but would be useful. (Or can we see it somewhere in the session?)
d

dmitriy.novozhilov

03/27/2024, 12:33 PM
FIR frontend was designed with the idea of locality So actually there is almost no places which know about the whole tree Also in IDE there is completely no such thing as "the whole tree", as it creates local fragments of tree on the fly and drops it constantly
t

Tóth István Zoltán

03/27/2024, 12:36 PM
That's understandable, but it makes me confused a bit as well. Mostly because you actually need the information, correct me if I'm wrong, but that's why the predicateBasedProvider exists. Anyway, I'll live with this and use only IR.
d

dmitriy.novozhilov

03/27/2024, 12:37 PM
predicateBasedProvider
is needed only for plugins Compiler doesn't need any kinds of lookups except lookups by full class name/simple name in scope
t

Tóth István Zoltán

03/27/2024, 12:38 PM
Yes, that's my point, the information is needed for plugins. 🙂
d

dmitriy.novozhilov

03/27/2024, 12:40 PM
And here we, as compiler developers, have a free will to decide what is available for plugins and what isn't, so everything will fit to the implementation design used in the compiler itself Plugins also need arbitrary syntax macroses, but it doesn't mean that they ever will be implemented
2 Views