I would like to generate a class for top-level functions that match a given criteria. I'm thinking a...

# compiler

[Tóth István Zoltán]

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?

[Javier]

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.

[Javier]

So you are forced to use predicated one (annotations) or hardcoded values you already know

[Tóth István Zoltán]

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.

[Javier]

AFAIK in generation the predicated provider only works with annotations. It is more powerful on checkers.

[Tóth István Zoltán]

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.

[Tóth István Zoltán]

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.

[Javier]

That is what is weird to me, I wouldn’t expect you get it working for classes

[Tóth István Zoltán]

No, I mean I need something similar for the top-level functions.

[Tóth István Zoltán]

For classes it works well.

[Javier]

Yeah, I understand, what I mean, is the opposite, you should not be able to get that in classes, and you are getting it

[Javier]

@dmitriy.novozhilov is that behavior expected?

[Tóth István Zoltán]

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.

[Javier]

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.

[Javier]

I don’t know if your use case is an exception or a bug/leak

[Tóth István Zoltán]

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.

[dmitriy.novozhilov]

But I don't know how to get all the top level functions of the package

You can't

[Javier]

Have you tested your plugin in an IDE?

[Javier]

Take care, some things work in tests but later in the IDE they do not exist

[Javier]

For example getting data from other modules was working in tests and it was totally null in the IDE

[Tóth István Zoltán]

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.

[dmitriy.novozhilov]

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óth István Zoltán]

I do it with IR atmn. I was thinking being good and doing it with FIR. 😄 But I'll just skip it then.

[Tóth István Zoltán]

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?)

[dmitriy.novozhilov]

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óth István Zoltán]

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.

[dmitriy.novozhilov]

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óth István Zoltán]

Yes, that's my point, the information is needed for plugins. 🙂

[dmitriy.novozhilov]

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