- Introduce new definitions in descriptors.proto
- Add new corresponding values in Flags.java
- Introduce ContractSerializer and ContractDeserializer, responsible for
for conversion ContractDescription <-> ProtoBuf.Contract
- Add dependency of 'serialization' module on 'resolution' so that it
could see contracts model.
Note that here we do a lot of seemingly unnecessary hoops, which in fact
necessary to respect existing module system (in particular, to be able
to extract ContractDescription declarations from 'descriptors' module to
make them invisible from reflection)
==========
Effect System introduction: 8/18
This function is now used instead of allImplementingCompatibleModules,
thus allowing it to be deleted together with allImplementingModules
So #KT-17369 Fixed
So #KT-17374 Fixed
May fix also some other MPP issues
LanguageVersionSettings doesn't mean that the module is actually
multiplatform; it only means that it _could_ be one. Use
platform and information from facet instead.
Also fix detection of common stdlib version and add tests for common
run config.
Now unsafeResolveToDescriptor is equivalent to resolveToDescriptorIfAny
but throws exception in case no descriptor is found.
Old version of resolveToDescriptor is kept intact but made deprecated.
Some clarifying comments were added
The main changes are in jvm_package_table.proto and ModuleMapping.kt.
With JvmPackageName, package parts can now have a JVM package name that
differs from their Kotlin name. So, in addition to the old package parts
which were stored as short names + short name of multifile facade (we
can't change this because of compatibility with old compilers), we now
store separately those package parts, which have a different JVM package
name. The format is optimized to avoid storing any package name more
than once as a string.
Another notable change is in KotlinCliJavaFileManagerImpl, where we now
load .kotlin_module files when determining whether or not a package
exists. Before this change, no PsiPackage (and thus, no JavaPackage and
eventually, no LazyJavaPackageFragment) was created unless there was at
least one file in the corresponding directory. Now we also create
packages if they are "mapped" to other JVM packages, i.e. if all package
parts in them have been annotated with JvmPackageName.
Most of the other changes are refactorings to allow internal names of
package parts/multifile classes where previously there were only short
names.
Header/impl declarations are now considered fully compatible even in the
case when the impl declaration has no "impl" modifier. The error about
no "impl" is now reported separately and only on the impl declaration,
never on the header declaration
#KT-20087 Fixed
Mikhail Glukhikh