See the previous commit for information on the kotlin-reflect vs
kotlin-reflect-api distinction.
Add kotlin-reflect as an explicit runtime dependency of most of the test
configurations because even though they all depend on tests-common, the
runtime dependency on kotlin-reflect is not exported from tests-common
to other modules because the projectTests dependency is not transitive.
The new name is more convenient and precise because this module is no
longer only about loading declarations from Java, it also contains
implementation of loading Kotlin declarations from .class files, as well
as type mapping abstractions, JVM ABI specifications, etc.
- 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
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.
Unlike the JVM target platform, the JS back-end does
not track getters' and setters' usages separately,
so when either accessor of some property is changed,
all usages of that property will be rebuilt.
Previously ProtoCompareGenerated could
go out of bounds when comparing protos
with different number of annotations.
That happend because JsProtoBuf.parameterAnnotation
is a repeated extension, but the generated code for
comparing repeated extensions was incorrect.
JvmProtoBuf does not have repeated extensions (at least for
the class and package descriptors),
so the problem was not detected before.
Alexander Udalov