No package annotations are going to be loaded, and
TypeQualifierDefault/TypeQualifierNickname are no longer recognized by
default. Use the CLI argument "-Xload-jsr305-annotations" to enable this
behavior back
#KT-10942
It was only used for type-related nullability/mutability
annotations and it was necessary to remove them
in the descriptor renderer (duplicating their fqnames there).
At the same time they're only needed for types enhancement
where they can be simply restored from type owners' descriptors
The testData changes are more or less correct: this kind of annotations
is bound both to types themselves and their use because of their targets
As the type is anyway replaced with not-nullable version
explicitly, the only thing that changes is what type is loaded
for String[][].class:
- before it would be Array<Array<String?>?>
- now it's Array<(out) Array<(out) String!>!>
It's both a minor change and new behaviour can be considered
as correct
It's only used for choosing mutability of a collection class, but
using annotations while loading is redundant since there is
a separate phase of type enhancement where they're taken
into account (for flexible types)
For inflexible type it doesn't matter since they appear only in
special cases like annotation methods (where collection classes can't be met)
The only sensible usage of them was in the `isNullable` method
But you can check that UPPER_BOUND/SUPERTYPE_ARGUMENT are always
flexible and TYPE_ARGUMENT is not only in case of annotation
methods/parameters
Before computing the FqName, check the simple class name first. This
code was responsible for about 20% of FqNameUnsafe instances created
during compilation of "core" modules
This fixes the exception in the case described in KT-14094 because we no
longer try to load annotations on functions which cannot be annotated
with @PlatformDependent. (However, the underlying problem in KT-14094 is
not fixed by this, and is still reproducible on explicit call to
KCallable.annotations.)
#KT-14094 In Progress
- Move the following from 'deserialization' to 'descriptors':
NotFoundClasses.kt
AdditionalClassPartsProvider.kt
ClassDescriptorFactory.kt
PlatformDependentDeclarationFilter.kt
findClassInModule.kt
- Move the following form 'descriptors' to 'deserialization':
BuiltInSerializerProtocol.kt
builtInsPackageFragmentProvider.kt
- Extract a marker interface from BuiltInsPackageFragment and move its
implementation to 'deserialization'
- Change the type of parameters in PlatformDependentDeclarationFilter
and AdditionalClassPartsProvider to ClassDescriptor
This will help in getting rid of the circular dependency of
'descriptors' <-> 'deserialization'
The problem was that an overload of CodedOutputStream.newInstance
without size uses 4000 as a default value, thus allocating
a 4k-sized byte array.
At the same time the array remained effectively unused
in the most cases since it only used for storing data
for unknown fields.
Because such arrays are being created for each read of
protobuf message, during compilation of IntelliJ project
it was producing 25% of redundant memory traffic.
Of course these arrays were all in the young gen, but still
they have some effect on GC
Backend: If kotlin class extends kotlin.collection.List
write it as it's super interface (light class mode only)
IDE: Provide wrapper classes to java resolve
that try to emulate backend behaviour
For example if kotlin class implements kotlin.collections.Map,
we provide a superinterface that has abstract 'getEntries' method
and 'entrySet' method that is considered default.
In reality all those methods are generated in the class itself.
In IDE supporting this case without hacks is not feasible performance-wise
since kotlin.collection.* may not be an immediate supertype and we need
to compute all supertypes just to calculate own methods of the class
com.typesafe.akka:akka-cluster-sharding_2.12:2.5
akka.cluster.sharding.ClusterSharding has the following methods:
public static ClusterSharding get(ActorSystem var0) {
return ClusterSharding$.MODULE$.get(var0);
}
public static Extension get(ActorSystem var0) {
return ClusterSharding$.MODULE$.get(var0);
}
NB: ClusterSharding <: Extension
None of these methods is synthetic or something, but javac allows
calls like ClusterSharding.get(null) and they get resolved
to the first method returning ClusterSharding
It seems that both javac and IntelliJ resolution algorithms filter out
such clashing declarations choosing the one that has the most
specific return type, the same idea is applied in the change
#KT-17560 Fixed
Also add a findInnerClass method that can find an inner class
by its name
This change helps to avoid loading all the inner class files
eagerly (that may be rather slow), while all the names are available
in InnerClass attribute
The reason is that canonicalText requires some additional
computations to be done when reading class files, while
in fact we only need a class name of the type
Alexander Udalov