Use distJar configuration instead.
It's necessary because currently when using default-type, subproject
starts having a transitive dependency to :kotlin-stdlib-common
and that leads to exception from KT-20897 when building light classes
This change might be reverted once KT-23942 is fixed
#KT-23942 Submitted
As far as I can tell (and admittedly I'm not an expert in the Kotlin compiler code), it looks like the new logic iterates over all contributed descriptors, which renders the old logic (which explicitly invokes getCompanionObjectDescriptor) obsolete. We ran into this last year when rebasing on top of https://github.com/JetBrains/kotlin/commit/527ccaff16ecebbfbcecabd5fbc8af808a296915 and - after a quick conversation with @sandwwraith (email chain dated December 12, 2017) - we unblocked ourselves by deleting the old code from our local repository. Now we're looking to upstream our changes, thus this PR.
Old code:
```
// Generate synthetic (non-declared) companion if needed
ClassDescriptor companionObjectDescriptor = descriptor.getCompanionObjectDescriptor();
if (companionObjectDescriptor instanceof SyntheticClassOrObjectDescriptor) {
genSyntheticClassOrObject((SyntheticClassOrObjectDescriptor) companionObjectDescriptor);
}
```
New code:
```
// Generate synthetic nested classes
Collection<DeclarationDescriptor> classifiers = descriptor
.getUnsubstitutedMemberScope()
.getContributedDescriptors(DescriptorKindFilter.CLASSIFIERS, MemberScope.Companion.getALL_NAME_FILTER());
for (DeclarationDescriptor memberDescriptor : classifiers) {
if (memberDescriptor instanceof SyntheticClassOrObjectDescriptor) {
genSyntheticClassOrObject((SyntheticClassOrObjectDescriptor) memberDescriptor);
}
}
```
Change-Id: Icb51ee6e56b9928108cc121c78fa50c6354a4b31
Introduce COMMON_COROUTINES_TEST directive.
Every test with this directive is run twice: one time with
language version 1.2 and kotlin.coroutines.experimental package
and the other time with language version 1.3 and kotlin.coroutines
package. Each run is a separate method: with suffixes _1_2 and _1_3
respectively.
However, since codegen of release coroutines is not supported in JS
backend, we generate only one method: with suffix _1_2.
#KT-23362
StringTable.serializeTo was effectively only used for JvmStringTable,
but was declared in StringTable because of the usage in
DescriptorSerializer.serialize (which, in turn, was only used from JVM
codegen)
Also, fix the value of "hasAnnotations" flag to reflect if there are any
_non-source_ annotations on a declaration.
Unfortunately, after this change
IncrementalJsCompilerRunnerTestGenerated$PureKotlin.testAnnotations
starts to fail because of the following problem. The problem is that
annotations on property accessors are not serialized yet on JS (see
KT-14529), yet property proto message has setterFlags field which has
the hasAnnotations flag. Upon the full rebuild of the code in that test,
we correctly write hasAnnotations = true, but annotations themselves are
not serialized. After an incremental build, we deserialize property
setter descriptor, observe its Annotations object which happens to be an
instance of NonEmptyDeserializedAnnotationsWithPossibleTargets. Now,
because annotations itself are not serialized, that Annotations object
has no annotations, yet its isEmpty always returns false (see the code).
Everything worked correctly before the change because in
DescriptorSerializer.hasAnnotations, we used Annotations.isEmpty and the
result was the same in the full rebuild and in the incremental scenario.
But now we're actually loading annotations, to determine their
retention, and that's why the setterFlags are becoming different here
and the test fails
#KT-23360 Fixed
This allows to emulate current compiler behaviour
Introduce CombinedModuleInfo which is a combination of several other modules intended to be analyzed together
Local lateinit var differs in behavior from a simple local var,
and logic that relies of 'instanceof Local' checks assuming that all
instances of Local are simple local vars can produce faulty code
(as in KT-23260, where a local lateinit var was not explicitly put on
stack when passed as an argument to an inline function, thus causing
null propagation).
#KT-23260 Fixed Target versions 1.2.50
Support DONT_RUN_GENERATED_CODE in JS Box tests.
IGNORE_BACKEND_WITHOUT_CHECK is removed because of
it's often wrongly used and in most cases can be
replaced with IGNORE_BACKEND or DONT_RUN_GENERATED_CODE
or with combination of them.
Denis Zharkov