... 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
When snapshotting a classpath entry, sort information about types
so there is no dependency on the order of entries in jar.
Test: ClasspathAnalyzerTest
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.
Short description.
It's a corner-case with old MPP plugins and AS, so we
don't care too much that it works incorrectly, but we'd like to avoid
muting it in order to keep track of this "known issue"
Long description.
In IDEA, KotlinJvmTestMethodGradleConfigurationProducer successfully
returns run configuration; in AS, it fails to do so.
This is becasuse it doesn't override 'forceGradleRunner', which means
that in 'setupConfigurationFromContext' we'll delegate to super-call,
which will pull 'GradleProjectSettings.getTestRunner()'.
In IDEA, it will return GRADLE, but in AS it will return PLATFORM,
because AS uses special instance of GradleProjectSettings which forces
runner to PLATFORM.
Note that KotlinMultiplatformJvmTestMethodGradleConfigurationProducer
does override 'forceGradleRunner' to true, that's why other tests work
successfully. However, this test uses old 1.2.X-MPP plugins, therefore
all new KotlinMultiplatform*ConfigurationProducers won't work here.\
Kristoffer Andersen