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.
Yan Zhulanow