The issue was reproducible when the same package is present in different
modules with the same -module-name (which is a popular case of src/test
roots in simple IDEA projects). The problem was in the fact that several
resource files containing package name mapping with the same name were
present in the classpath, but RuntimePackagePartProvider only considered
the first one. The fix is to use getResources instead of
getResourceAsStream and handle each returned resource.
Also, optimize internal representation to store the mapping in the form
which is the most convenient for findPackageParts, which should be
faster than registerModule because in theory, it's called more often.
#KT-21973 Fixed
#KT-24651
This is now fully covered by the JVM signature mapping, introduced in
the previous commit. The change in KDeclarationContainerImpl.methodOwner
is needed because primitive classes have no methods on JVM; and when
we're looking for "Int.equals", we'll now look it up in the Class object
for java.lang.Integer, not for the primitive int.
There are cases when members deserialized from JVM classes have no JVM
signature in the proto. For example, if a member is inherited from a
built-in class (such as Map.getOrDefault in some Map implementations),
or if a member is synthesized in the compiler front-end and back-end
separately (such as enum values/valueOf). In these cases, we'll use the
naive type mapping to try to recover the signature.
#KT-16616 Fixed
#KT-17542 Fixed
The only client of this data is reflection, and since anonymous objects
do not have constructors in the source code, they shouldn't in
reflection as well
#KT-20442 Fixed
The change in DescriptorSerializer is needed so that serialized protos
of enum entry classes which are resolved in sources
(LazyClassDescriptor) and are deserialized from binaries
(EnumEntrySyntheticClassDescriptor) are the same. There are tests on
incremental compilation in JS that check that the serialized proto is
exactly the same after rebuild and after an incremental build.
#KT-22048 Fixed
There's still some blind spots:
- Covariant overrides in Java (KT-25036)
- Current implementation assumes that when language version is 1.3 every suspend function
reference only release-coroutines-package Continuation
(we need to check if it's a correct statement)
#KT-24848 Fixed
#KT-25036 Open
Alexey Sedunov