Few comments regarding the FIR and BIR apis

[raulraja]

DO NOT MERGE.

This PR contains a few comments regarding our experience using the Frontend and Backend IR to build compiler plugins.

All comments start with (FIR API review and comments), code related changes can be ignored.

[demiurg906]

It's impossible, because it won't work in IDE, because it will require resolution of the whole module to TYPES stage, which will be very slow

[demiurg906]

I agree, it may be not the best syntax. I just thought at some point that it looks pretty nice, but I'm not sure about it right now

[demiurg906]

Indeed, session components are not available in backend. But you can use something like that:

class ProofCache

class ProofCacheStorage(session: FirSession, val proofCache: ProofCache) : FirExtensionSessionComponent(session)

private val FirSession.proofCacheStorage: ProofCacheStorage by FirSession.sessionComponentAccessor()
val FirSession.proofCache: ProofCache
    get() = proofCacheStorage.proofCache

[raulraja]

Nice!, we will try to refactor to that

[demiurg906]

Keys can be used for passing some information from FIR to IR. We save a plugin key in IrDeclarationOrigin, so you can create it in frontend generator and then read it from the IR for this declaration

We're considering different approaches for such data translation (e.g. by introducing declaration attributes for IR declarations), but for now this is the only way except some external service

[raulraja]

Makes sense and this clarifies it.

[demiurg906]

It's a price for builder functions instead of constructor calls. There are two things which we possibly can do with it:

1. Write proper documentation
2. Introduce safe builders feature (actually, I want to do it for four years, because it was the topic of my master degree, but the most optimistic estimate I can give is release of FIR, which mostl likely will be 1.10)

[raulraja]

We are very interested in safe builders as well, if there is anything we can do to help there even if in the future let us know. :)

[demiurg906]

Design for them was done a long time ago. So now we need to actualize it and implement it in the FIR.
The thing is that we don't want to do it in both frontends

[demiurg906]

Yeo, it won't be possible to modify existing resolution. But I think we can simplify API for custom calling of FirCallResolver. Please create a feature request for it in the YT

[demiurg906]

It would be nice to have some helpers to simplify generating FIR and IR as part of the compiler API. I faced with such boilerplate issues myself and I don't like it.

You can create such helpers by yourself and send them as PR, it would be very helpful

[demiurg906]

It's a known issue, I'll work on it

[raulraja]

thank you!

[demiurg906]

We had FirNamedDeclaration before, but then we decided to discard this interface, because there is no actual point in it. Named declarations don't have anything in common except the name. You never work with a collection of just declarations, you need to split them into class like declarations and class like declarations and treat them differently. I don't see any usecase where logic in plugin depends only on the name of declaration, but don't' distinguish classes and functions

[raulraja]

In this case, this plugin generically depends on callable declarations having a name for rendering providers.
This plugin support these different kinds of providers.

val foo: Foo = Foo()
fun foo(): Foo = Foo()
class Foo
object Foo

All of them have a name, but it's not a big deal, we thought it made sense because others like Type Parameters containers have their own interface type.

[demiurg906]

class and object are not callable declarations

[demiurg906]

BTW this implementation is incorrect

val FirDeclaration.declarationName: Name
    get() = when (this) {
        is FirCallableDeclaration -> symbol.name
        is FirClassLikeDeclaration -> symbol.name
        is FirTypeParameter -> name
        else -> error("Unsupported declaration ${this.renderWithType()}")
    }