* unify various checks for whether a suspend function needs a
continuation;
* mark the continuation parameter with an origin (this also allows
correctly computing the offset of the local in codegen -- see the
new test);
* when wrapping `suspend fun main`, use a suspend reference instead of
a synthetic non-suspend lambda (required to correctly implement the
previous point, as previously the continuation parameter was passed
to main() itself correctly only because of very lenient checks in
AddContinuationLowering).
We can't reuse caches from different platform when we compile against
different jar on each platform. Since they have same api we may use
platform specific jars only for runtime.
Previously it was 'constructor-' + hash in case inline class property is
of inline class type.
No new tests added because this change fixes the constructor name in
`bytecodeListing/inlineClasses/inlineClassWithInlineClassUnderlyingType.kt`,
which is now failing due to other reasons.
#KT-37041 Fixed
#KT-37186
... for an _even leaner_ codegen!
- move discard from extention method to abstract method. This will at
length avoid some calls to materialize.
- use newly abstract method to specialize discard in cases where it
would introduce _and_ coerce values only to be popped by discard.
- move coerce to member method, introduce materializeAt with a view to
eliminate calls to coerce outside of PromisedValue. This will allow
us to specilaize materialization at particular types in some
instances, at length avoiding casts etc.
- no calls to coerce outside of PromisedValue.kt! Progress.
- inlined coerce into materializeAt, anticipating specializing
materializeAt across implementations of PromisedValue
- made materializeAt abstract, copied implementation everywhere!
- made materialize an extention function! Ready to specialize materializeAt
- coerce is no more!
- simplified and specialized all inlinings of materializeAt.
- adjust docs to match refactoring
This commit is a hotfix rather then proper solution.
The source of the issue is that currently type variable fixation result
may change due to fixation order alteration for variables with the same priority.
For instance, having variables V1, V2, and proper types Type1, Type2, such that:
V1 <: Type1
V1 <: V2
Type2 <: V2
both variables will be fixed either to Type1, if V1 will be fixed first,
or to Type2 otherwise.
Since this limitation cannot be easily overcome, the taken approach is to remove
incedental constraint added after 2d5a0546 by restricting nullability constraint check
to `Nothing?` constraints only, thus postponing problematic variable fixation.
To clearify, additional constraint is correct and should cause no harm (in ideal world),
but currently its presence changes fixation order.
So without the restriction the previously used constraint from fixed outer variable
is no longer available by the time problematic variable type is being selected.
^KT-37043 Fixed
Roman Artemev