* 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).
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
The bug appeared when we turned “ultra light classes” on by default.
The difference with the old implementation is that
PsiClass.getTextRange() returns the correct non-null value.
This triggers JavaExecutionUtil#stepIntoSingleClass() to return
a light class instead of the original location (of a PsiIdentifier).
So AbstractJavaTestConfigurationProducer#isConfigurationFromContext()
returns true, and the wrong configuration is reused instead of
creating the new one.
By the way, for Java it also returns an identifier because of the
PsiTreeUtil.getParentOfType(element, PsiClass.class) != null check.
The proper fix should land in the newer versions of IDEA, however this
(hopefully, temporary) hack will fix test method gutters for
all platform versions.
Use resulting descriptor extension receiver type instead of
ReceiverValue.type (which can contain captured types, which would be
approximated, and cause IR validation errors).
The number of initializations of the `value` field before the live range
begins does not really matter so long as we insert a write of a default
value to the local if there were none.
See KT-36812. Aside from the problem stated there, D8 will throw out the
entire LVT if it sees a variable that has not been written to (and will
generate incorrect SSA if the slot is reused with a different type).
Note: this only fixes a FIR test because it's missing an `else -> throw`
branch, and default initialization satisfies the verifier and masks the
incorrect control flow.
pyos