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
NB: for-in-until loop is generated as precondition loop, because the
corresponding range is right-exclusive (and thus we have no problems
with integer overflows).
#KT-10397 Fixed
According to JVMS (p. 4.3.4) inner classes should be separated with `$` in generic signature.
Note that in Java, inner types separated with `.` after first parameterized type, and now we preserve the same behaviour. See tests for clarification.
Local returns normalization can generate POP instructions.
These POP instructions can drop functional parameters, as in KT-17590,
and should be processed in markPlacesForInlineAndRemoveInlinable just
as other POP instructions.
KT-17590 conditional return in inline function parameter argument causes compilation exception
It never terminates, so the corresponding value on stack can't be used.
However, if this happens in an inlined lambda argument, the inliner is
unable to remove the corresponding ALOAD instruction (because default
handler never terminates, and thus corresponding ALOAD is not used for
lambda invocation).
KT-17573 try-finally expression in inlined function parameter argument fails with VerifyError
When a try-catch expression is passed as an argument to the inline
lambda parameter, lambda variable on stack is spilled and restored in
several different locations (1 for try-block, 1 for each catch-blocks).
So it's possible that lambda to be invoked comes from multiple loads,
all of which should have the same "root" lambda parameter.
In cases like KT-17384, where 'break' or 'continue' happens in an argument
to an inlined lambda call, fix-stack transformation sees corresponding
ALOAD for lambda, and inserts corresponding POP instruction before jump.
However, this ALOAD is later removed during inlining.
So, we should also remove the related POP instructions.
Applying plugins leads to failures when matching members in LazyLightClassDataHolder
because plugins rely on analysis results
This decision has its drawbacks (java won't see results of plugin execution)
but more work on light classes is needed if we want to support this usecase
We can argue that plugins should only generate synthetic members
but there is no such restriction atm
Before this fix line numbers for function call arguments were not generated,
so if argument was on another line than function call it was
impossible to stop on argument line during debugging.
Now line number for each argument is generated if necessary
(another line than function call line).
#KT-17144 Fixed
To get rid of pointless/confusing implementations in ModuleDescriptor,
PackageViewDescriptor, TypeParameterDescriptor and others.
Note that there are still implementations that do not make sense, for
example in those subclasses of VariableDescriptor which are not also
subclasses of CallableMemberDescriptor (e.g. ValueParameterDescriptor).
Those can be removed by making CallableMemberDescriptor (instead of
CallableDescriptor) inherit from Substitutable. However, that would
require more changes in the compiler because CallableDescriptor is used
rather often in places where in fact only CallableMemberDescriptor
instances can appear.
Explicit return types and casts are required in some places now because
there's no single non-trivial supertype for
ClassifierDescriptorWithTypeParameters and CallableDescriptor.
Previously it was DeclarationDescriptorWithVisibility, now it's both
that and Substitutable<...>
Codegen generates clean instructions for ref values (captured vars)
on block exit so we should delete them on dereferencing captured values.
#KT-17200 FIXED
To provide consistency between light classes and their delegates
IdeLightClass#testExtendingInterfaceWithDefaultImpls still failing since
we do not generate implementations delegating to DefaultImpls of superinterfaces
Class APIs from java point of view stays the same so we can avoid generating those methods
Otherwise we have to calculate all supertypes when getMethods() is called,
which imposes severe performance penalties
We have to pretend these methods are not 'abstract' (also we consider them 'default' for safety)
so java highlighting does not report "class should be abstract" for all inheritors
We have to manually report "class should be abstract" on some of the java inheritors,
specifically those that are implementing interfaces directly
as opposed to extending kotlin classes implementing those interfaces
Stop at function start on step into.
Step at function end on step out.
Both cases should actually be skipped by debugger, but this is postponed
till new backend generation for suspend functions is ready.
#KT-16025 Fixed
Replace `takeIf { !expr }` with `takeUnless { expr }`.
Cleanup redundant parethesis as in `listOf((expr))`.
Replace `listOf(expr)` with `expr.let(::listOf)` where the former caused significant indentation change.
Denis Zharkov