https://kotlinlang.org logo
Join Slack
Powered by
Arrow-meta has the ability to hook into the front-...
# arrow-meta
a
Arrow-meta has the ability to hook into the front-end and the intermediate code-optimizer
šŸ‘ 1
Now I'm trying to fit that in with the different models that Kotlin uses in particular - Psi/AST, Descriptor models, and IR
I know that PSI is a layer over the AST structure, and that descriptors contains types and potentially PSI (if they're not synthetic)
r
PSI is the AST
the PsiElements have the node elements
then Psi gets enhanced with descriptors in what diagram calls the Semantic Analyzer
Which in meta that is the analyzer and resolution phase
then once the AST is given meaning and there are both PSI elements and Descriptors with the Kotlin info it proceeds into codegen if it all typechecked properly and that is the Non-Optimized IR generated in that diagram
šŸ™ 1
šŸ‘ 1
because once you hand the IR back to the compiler after your transformations it can do further optmizations before generating the classes
a
Ah okay - according to my notes (I can trace back the sources if need be), the semantic analysis stage is responsible for building the symbol table and performs type-checking here
Which part is both the analyzer and resolution phase again?
r
analyzer builds the symbol table in the resolution. In the kotlin compiler there are two symbol tables. This is the resolution one that happens first and we call this the 
BindingTrace
which is the map where symbols are associated to their types. There is a mirror of this in IR where there is symbol table for IR symbols. the IR Symbols can be obtained given you have the descriptors obtained from resolution.
The Analyzer and Resolution in that diagram would be the Semantic Analyzer which produces the Arrow that says AST + Symbol table
that literally is adding descriptors to PSI which have been typechecked and have the found symbols
then those same symbols have an IR representation in the IR symbol table
That diagram is wrong in the sense that while the Kotlin compiler has a 
Frontend IR
known as FIR, itā€™s highly experimental and incomplete
So in practice the Kotlin compiler Backend part would start before the the 
IR Code Generator
which there is inside the frontend
that is the current status
so in the same way you draw a big baloon for the frontend you should for the backend and then it will reflect the state of the compiler internals
What it says there is a ā€œBackendā€ in kotlin would be the MPP codegen to each platform
Although some people call that a backend
a
oof okay, let me try to get a reworking in
r
I guess Backend just mean anything after typechecking and the impl of what is discovered after analysys and resolution
At least this is how I see it but other people may have different opinions
This is all largely made up based on what I see itā€™s organized internally
a
I'm not sure, folks referred to the backend with more manual processes
The backend takes the optimized IR and performs more analysis, transformations and optimizations specific to CPU architecture, maybe working on multithreading and other kinds of jobs that require certain allocations
Within the front-end compiler, there is the ability for lexical, syntactical, and semantic analysis. But talking about how this plays with the models of the compiler (IR, FIR, Descriptors, AST/PSI) really helps starting to clear some fo this, but I've been slow at going back to correct some of this stuff!
r
It took me a long time to understand too specially since the only docs is the code for the most part but we cleared most of it already
a
That's what I was just talking about in another thread! I basically have to go through this cookbook, which only talks about the IDE plugin for the language and only talks about the code system they wrote, and so I have to cross-reference what they write with academic research/other resources
But it's still not the best way, because I know their system is "loosely based". I was aware of FIR and IR, but I was not aware that there were actually 2 symbol IR tables until you told me
In fact, I've been kind of ignoring FIR this whole time because it's been useless to me so far
r
It's natural. Compiler plugins are not officially supported and the Kotlin compiler is in rapid evolution to accommodate MPP so resources are spent elsewhere. I'm grateful though I went through the struggle because I would have not learnt as much and many people from the compiler and community helped me
šŸ˜® 1
šŸ˜° 1
We will pioneer docs with meta and that would be a good contribution to the compiler and tooling ecosystem
šŸ™Œ 1
šŸ¤˜ 1
7 Views
Open in Slack
PreviousNext
Powered by