Replace it with a dependency on 'descriptors'.
Move the existing marker interface ContractProvider to 'descriptors',
and create a new marker interface DeserializedDescriptor.
Move ParseUtils to 'psi', and ImportPath to 'frontend.common'.
Now 'psi' depends on 'frontend.common', and that allows to remove
dependency of 'fir:tree:tree-generator' on 'psi', allowing the former to
compile in parallel with the old frontend code.
Also move version string regex there and rename the class to
RequireKotlinConstants. This allows to get rid of dependency of
'serialization' on 'frontend'.
This allows to replace dependency on 'js.frontend' with 'js.config', in
'kotlin-build-common' and 'daemon-common'. Also simplify some other
dependencies.
This allows to get rid of dependency of this code on CommonPlatforms,
which depends on all platforms (JVM, JS, Native), and eventually move it
to 'frontend'.
The mental model for inline functions/lambdas is as following:
inline functions have the `inline` keyword before them so it makes sense
for their bodies to be copied at call sites although the compiler might optimize
that if there is no usage of reified type parameters or crossinline value parameters.
But since there is no `inline` keyword around an inline lambda, then
it is logical to think that there will be no copy of it and that it will be just embedded
at the corresponding call site as is.
If an inline class is mapped to a reference type (or an array), it's Ok
to treat JVM view on a suspend function as returning a value of
corresponding inline class (although in reality it returns 'Any?'
because of COROUTINE_SUSPENDED).
Fix line number generation for assignments where the right-hand
side of the assignment is not on the same line.
Fix line number generation for intrinsics functions where the
function is not on the same line as the last argument.
Be careful to not break stepping behavior with the iinc
optimizations.
We can only use IrStrinConcatentation to represent calls to Any?.toString
and toString calls on primitive types. Otherwise, x.toString() and "$x"
are observably different when x is a non-null type with null value
(e.g., an @NotNull value coming from Java).
Ilya Goncharov