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
When the JavaCompile tasks were removed from a common project, some of
the dependencies on them remained. This could lead to an error during
dependencies resolution, such as the one in KT-23092. To an even greater
confusion, the remaining dependencies anyway led to the task being
added to the task graph.
Issue #KT-23092 Fixed
JVM tests check only single class result, in order to reuse test data
JS tests should do the same. CHECK_PACKAGE is introduced to override
this behaviour explicitly.
- Since warnings are discarded when there are others errors, replace the
current warning by an error to always display the message and inform the
user that its annotation processor is badly configured.
Fix of https://youtrack.jetbrains.com/issue/KT-23721
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
Copy everything from kotlin.coroutines.experimental to
kotlin.coroutines. The latter is separate source set to be packed into
separate kotlin-stdlib-coroutines.jar
#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)
Pavel V. Talanov