The KlibMetadataSerializer used to serialize all package fragments that a module
could provide, including those coming from the module's dependencies. In order
to produce a klib from a module that is analyzed by the K2MetadataCompiler, the
serializer needs to take just the own package fragments of the module, excluding
those of the dependencies.
Fix NPE for case when target path for package is not exists
Clarify case when target path for file move does not exists
Fix NPE when file selector shows with empty edit box of file name in Move dialog
- Fix `toString` evaluation for unsigned types in FoldConstantLowering
- make corner cases around float/double evaluation work for K/JS
- remove usage of kotlin type
Even if annotation processor classpath is the same, in case
individual entries change (e.g. bulding annotationo processor
from source), KATP should run non-incrementally.
Test: KaptIncrementalWithIsolatingApt.testUnchangedAnnotationProcessorClasspathButContentChanged
Just some syntax cleanup when visting the file.
Note: I was trying to understand why the output folders of kapt are creating so eagerly in a build, during configuration time indeed...(they should be created later, during execution).
The idea is the same as in case of anonymous objects: they are created only
from Kotlin code, so we are sure, that the parameters are valid.
Also, the inliner complains on their transformations.
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.
victor.petukhov