Add a convenient way to specify Kotlin compiler
plugin options with the CompilePluginConfig,
which is added to the -api subproject.
^KT-50869 In Progress
This is needed to avoid bundling of FIR classes to IDE plugin for
parcelize, because it can cause compatibility issues, because
IDE plugin does not contain FIR compiler
This commit fixes DFA problem (see test) when we accidentally try
to merge incoming flows from member property (val ... by cached ...) and
the following function. While completing lambda of buildList { ... }
inside by cached we accidentally assume that delegate is already left
and add the lambda into exitsFromCompletedPostponedAnonymousFunction.
This commit fixes the problem by exiting delegate later, after completion.
This commit saves us some performance and fixes test for KT-35684.
FIR-based constraint completer at this moment can't extract type
variables from already completed calls.
Folding allows us to extract ordered type variables before completion.
In this commit we upgrade FIR builder inference logic from
the compiler version to 1.7. FIR-based compiler now works with
"don't use builder inference" flag always ON and supports switching
the flag "use builder inference only if needed". To do it,
ContraintSystemCompleter (FIR) and KotlinConstraintSystemCompleter (FE 1.0)
are made similar with extracting some common parts into
ConstraintSystemCompletionContext.
Test status: one BB test fails after this commit (KT-49285).
Also we have a crush in DFA logic in FIR bootstrap test and somehow
questionable behavior in FIR diagnostic test. However,
two BB tests were fixed, the 3rd case from KT-49925 were also fixed.
#KT-49925 Fixed
Intentionally use doFirst section to trick gradle and not affect
inputs with absolute path usage.
Old behaviour can be returned by kotlin.build.use.absolute.paths.in.klib
in local.properties
Should be removed after KT-50876 fix.
^KTI-730 In Progress
Result of calling `ExpressionCodegen.gen` was used only in two call
sites in the inliner. In all other call sites, we were doing unnecessary
work (and sometimes were even failing) by trying to construct a
KotlinType instance out from an IrType.
Note that even though the code from KT-50617 no longer fails to compile,
the underlying problem is still not solved, since the IrType for foo's
dispatch receiver is constructed incorrectly. The reason is that
SymbolTable links everything by IdSignature, which is identical for
classes with the same FQ name.
#KT-50617 Fixed
Yahor Berdnikau