ScopeTowerProcessors.kt contains a few code snippets
that look like `collectCandidates(...).filter { ... }.map { ... }`.
Filter argument is always side-effect free, so it is safe
to merge `filter` and `map` calls into one for-loop.
The change also makes sense, because modified functions are quite hot.
For example `NoExplicitReceiverScopeTowerProcessor.simpleProcess`
produces 11,392,768 ArrayList instances (~1.08% of all objects)
when compiling the compiler according to aprof at the moment of writing.
On my machine the change improves compilation speed of the compiler up to 5%.
Now it's impossible to determine by descriptor if there is
a state machine for function, but at the same time
it doesn't really matter here since there is no LINENUMBERs
in doResume of continuation implementations for named suspend
functions
#KT-17585 Fixed
#KT-16603 Fixed
The reason is that when it gets captured into the field
having name $$continuation inliner fails with an exception
as it skips fields starting with '$$'
At the same time it doesn't really matter how to call
that parameter because it's only visible in Java
#KT-17585 In Progress
#KT-16603 In Progress
The main idea is to leave all the inline functions as is, without
state machines (but keeping suspend-calls markers) and
determine whether we need a state machine from the bytecode
after inlining into a non-inline function
#KT-17585 In Progress
#KT-16603 In Progress
#KT-16448 Fixed
It has been introduced in 2286027bed
and should've help to avoid verify error
Now it became both impossible and unnecessary:
- It's impossible now since we can't determine in codegen
if we'll needa state machine
(it depends from inline functions' contents)
- It's unnecessary since we'll introduce the state machines for cases
described in the 2286027bed tests
NB: There's still a problem that now we work a bit suboptimally
because actually these samples can be generated without state
machines
It helps to simplify implementation of generating state machines
into the named functions' bodies but of course has some flaws:
1. They may be called from the same package in Java
2. It may lead to problems when declaring clashing descriptor
in an inheritor
This change must be reverted at some moment, or these flaws
should be fixed in some other way
#KT-17585 In Progress
#KT-17584 Open
It's necessary because ASM remebers exact types obtained from
value parameters, and in the further commits we're going
to place code of suspend functions in their bodies, and there
we get already refined type for int-like slots
Initially it was a sort of hack: introducing another
interception class builder factory that will process all functions.
To differentiate suspend functions from the common ones
the fake annotation class has been used.
The problem is that now we should inject the different
class builder into the CoroutineTransformerMethodVisitor:
we need class builder for anonymous class representing state
for named function while currently it will be the one for the class
where the named function is defined
`CompilerMessageSeverity.OUTPUT` was removed from the enum set
`CompilerMessageSeverity.VERBOSE` in the commit d8d3bafbe9,
so `GradleMessageCollector` started to throw the exception.
#KT-17711 fixed
Friend modules should be provided using the -Xfriend-modules flag
in the same format as -libraries. No manual configuration required for
JPS, Gradle and Maven plugins.
Friend modules could be switched off using the -Xfriend-modules-disabled
flag. Doing that will
* prevent internal declarations from being exported,
* values provided by -Xfriend-modules ignored,
* raise a compilation error on attemps to use internal declarations from other modules
Fixes #KT-15135 and #KT-16568.
Allow to run kapt in "annotation processing only" and "stub generation only" modes in order to support incremental compilation in Gradle.
Unfortunately, annotation processing can't be done incrementally cause it uses all module files, but the stub generation can be done incrementally.
Mikhail Zarechenskiy