I'm reading the rust compiler docs. I'm interested...

# compiler

[mcpiroman]

I'm reading the rust compiler docs. I'm interested on how does the compiler team see their approaches, most notably the query and, built on top of that, the incremental compilation system.
In Kotlin, the backend uses simple phase based lowering and in frontend, it looks like K1 was kind of like the queries (map based) but now FIR moves again to a way similar to the backend.

Was something like the rustc does considered?
I think this is a pretty obvious approach, I've successfully implemented it in a data-analysis program and I plan to do something alike in a game (both written in Kotlin).
But then I don't really know how do the actual performance and convenience compare with such a huge project; it's possible that Kotlin does not allow to define appropriately efficient data structures as a rust would.

[dmitriy.novozhilov]

Yes, we considered query style from rustc, but we thought about it too late (after 2-3 years of development), so changing frontend architecture once again would delay K2 release for another several years

There are four problems with query/lazy approach in K1
• bad memory locality (it's more because of BindingContext and immutable PSI, but still)
• bad code locality: no phases, so any call in frontend can trigger execution of any other piece of frontedn. This leads to the problem when code cache of CPU is overflows and CPU just waits when it will be loaded from RAM instead of doing something useful (it's partially fixed with phased approach, but the problem still exists on big phases like body resolve, because it's just a lot of stuff we need to do during this phase)
• with lazy approach it's extremely hard to depevelop compiler. You don't have any restricted contracts on code, so your mind just blows during debugging. Also it leads to bugs which are quite hard to discover
• it is impossible to make K1 parallel with all this deferred computations
Most likely developers of rustc resolved some of those problems, IDK