intersect data flow value possible types
add intersection type (or exact type for the most cases) as a lower bound to constraint system
always get common super type for intersection type as a result
(avoid returning it, even in error messages)
the case when type parameter has number value types (constants) as lower bounds
should be handled specially, because upper bound for primitive number types is 'Number',
but by default we want Int (or Long)
- delete InjectorForJavaSemanticServices, replace its usages with
InjectorForJavaDescriptorResolver
- delete unneeded fields and parameters of InjectorForJavaDescriptorResolver
Class object properties' backing fields are generated into static fields of the
containing class, not into fields of class object. For fields we now store the
flag which, if set, tells that this field should be looked for in the
containing class
Package classes in line number tests only contain "1" as the first line number
of a single function, so there's no point in testing it. The test was failing
due to the latest changes in the order of generation of classfiles (first $src,
then facade)
Delete unused constants
Move constants related to abi to JvmAbi class
Constants related to annotation names are now in JvmAnnotationNames
Remove old annotation classes
Deprecate JetClass and JetPackageClass name constants
LoadCompiledKotlin and DescriptorSerialization tests should cover this.
KotlinClassAnnotationTest should only test that the correct annotation is
written
Serialize/deserialize package members via PackageData and
DescriptorSerializer.packageProto(), delete useless code
(JavaDescriptorFinder), extract some methods, etc.
This helps to get rid of "repeated class_name" field in Package protobuf
message. DescriptorFinder in resolve.java uses PSI to find all classes in a
package, and the finder for built-ins just reads .kotlin_class_names file
For top-level members, we now write a FQ name of the package$src class which
has the member's annotations, and read the correct file in deserialization
There was no place in bytecode where annotations on properties without backing
fields could be stored to. Now they're written on a synthetic empty void method
with a special name ("propertyName$annotations").
(Annotations on properties cannot simply be written on getters in bytecode,
since a getter can have annotations of its own.)
Instead of storing a string with the signature, write the name, return type and
parameter types separately, reusing the name table. Refactor the name table to
allow it to store not only names of Kotlin entities, but also arbitrary names
and fq-names
This is done because byte arrays in annotation arguments cannot be longer than
65535 bytes, and serialized data's length for kotlin.KotlinPackage class from
stdlib is already close to this number
Make 'Callable' message of descriptors.proto extensible, extend it in
java_descriptors.proto with a JVM signature of the member. This is needed in
order for annotation deserializer to find out which member in the compiled
bytecode corresponds to which descriptor in the hierarchy.
Create a new module 'serialization.java' containing everything related to
Java-specific serialization of descriptors.
Add an extension point to DescriptorSerializer, allowing to perform
platform-specific serialization on a callable
Svetlana Isakova