The main idea is the following: since we need to generate
(fake)continuations before inlining, we move IrClasses of suspend
lambdas and continuation classes of named functions into the functions.
Thus, it allows the codegen to generate them prior to inlining and
the inliner will happily transform them for us.
Because of that, lowerings which transform call-site function are likely
to change reference to lowered suspend lambdas or functions.
Hence, do not rely on references to lowered suspend lambdas or
functions, instead, rely on attributes.
Do not generate continuation for inline suspend lambdas.
Previously, inline suspend lambdas were treated like suspend functions,
thus we generated continuations for them. Now we just do not treat them
as suspend functions or lambdas during AddContinuationLowering.
We should add continuation parameter to them, however.
Do not generate secondary constructor for suspend lambdas, otherwise,
the inliner is unable to transform them (it requires only one
constructor to be present).
Generate continuation classes for suspend functions as first statement
inside the function.
This enables suspend functions in local object inside inline functions.
Since we already have attributes inside suspend named functions, we
just reuse them to generate continuation class names. This allows us
to close the gap between code generated by old back-end and the new
one.
If a suspend named function captures crossinline lambda, we should
generate a template for inliner: a copy of the function without
state-machine and a continuation constructor call. The call is needed
so the inliner transforms the continuation as well.
Refactor CoroutineTransformerMethodVisitor, so it no longer depends on
PSI.
This is a prerequisite to moving continuation classes inside said
functions, which is needed to support crossinline suspend lambdas.
The logic of whether to copy attributes on lowerings or not is simple:
- if the lowering moves function body to a new place, it should copy
the attributes.
- if the lowering just generates new declarations (i.e. bridges), it
should leave attributes as is.
This allows us to not generate redundant immutable collection
stubs. The code to generate the immutable collection stubs does
not deal well with thinking that all external declarations
come from Java.
Because of incorrect flag we generated synthetic SAM candidates and got ambiguity when feature `SamConversionPerArgument` was enabled (Gradle case) because candidates for Java were duplicated
#KT-35579 Fixed
MissingDependencyClassChecker.collectDiagnostics now show only unique diagnostics
As per-file analyzer trace used in checker delegates to resolve session trace, diagnostics might be duplicated because of race condition:
1. If a non-checker thread performs analyze first, diagnostics for global elements will be stored in the resolve session trace only once.
2 If the checker threads comes to the analyze first, diagnostics will be stored in the local trace, and after that might be duplicated in the resolve session trace by other analyzers.
#KT-35578 Fixed
Ilmir Usmanov