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.\
Dmitriy Novozhilov