This is only usedful for code splitting. The output .js file name
is provided by the build system during the module compilation.
It is desirable to keep the .js output file names same as in old BE,
but calculating those name during the klib -> js phase is tricky.
Thus the desired names are saved in the klib, and used later on.
This removes another dependency of 'ir.tree' on 'frontend', and among
other things, makes it possible to implement TranslationPluginContext
for FIR in the future.
This is needed in order to have a single convenient place where to
register frontend services implemented _outside_ of the 'frontend'
module, such as the control flow analysis, extracted to a separate
module in a subsequent commit.
Use general `AnalysisResult.CompilationErrorException` instead of
custom JsIrCompilationError to indicate about unsuccessful compilation
- Drop JsIrCompilationError
instead of statically registering it.
Static registering can cause subtle errors when plugin implementation
(e.g. SerializationDescriptorPluginForKotlinxSerialization) is registered
from multiple classloaders: in multi-module with daemon compilation scenario
#KT-41857 Fixed
Because IrPluginContextImpl constructor creates new instance of
BuiltinSymbolsBase (with symbols for stdlib declarations like `arrayOf` etc),
there should be at least one pass of `declareUnboundSymbolsAsDependencies`
between creation and usage in plugin. Such pass is located between psi2ir
and compiler plugins application. If plugin context is created inside lambda,
right before plugins are applied, the symbols will remain unbound.
#KT-41764 Fixed
A mechanism that allows kotlinx.serialization plugin to preserve the
correct (program) order of properties after serializing/deserializing
descriptors to kotlin metadata, which is needed for correct and stable
json serialization of class hierarchies in incremental/multi-module scenario.
It uses protobuf extensions.
Ilya Goncharov