There were two problems:
- For asm type `OBJECT_TYPE` was used, which can be wrong in case of
inline classes, because it can be an underlying value of some inline class
- For KotlinType, type from rhs was used
In 1.3, due to changes in language, testdata for some tests can be
different from 1.2
We want to simlultaneously test both versions, so instead of fixing
language version in such tests, we split them into two: one with fixed
1.2, another with fixed 1.3
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
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 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
Note that this is not relevant for LOCAL/INHERITED visibilities:
- for LOCAL visibility it's impossible to have a qualifier
- INHERITED is an intermediate visibility, we enhance it later
(see resolveUnknownVisibilityForMember)
#KT-20356 Fixed
After this change, optional expected annotations will be compiled to
physical class files on JVM, and stored to metadata on other platforms,
to allow their usages from dependent platform modules. For example:
@OptionalExpectation
expect annotation class A
When compiling this code on JVM, A.class will be produced as if the
class A did neither have the 'expect' modifier, nor had it been
annotated with OptionalExpectation. Note that if there's no actual
annotation class for A, then usages (which can only be usages as
annotation entries) are simply skipped.
Class A will be public from Kotlin's point of view (since it should
be possible to use it in Kotlin sources), but _package-private_ in Java
to disallow its usages outside of the declaring module.
#KT-18882 Fixed
#KT-24617 Fixed
varargs inside annotations will be supported later when
constant evaluation of more complex expressions of unsigned types
will be ready
#KT-24880 In Progress
Previous way to distinguish "primary constructor properties" from other
properties wasn't correct for deserialized properties, because currently
we don't have special information about this in metadata
Before this change, kotlin.suspend was being loaded as having a common
function type instead of suspend function type.
With LV=1.3, we expect that suspend function types should have
new Continuation interface as a last type argument, while
kotlin.suspend is built with LV=1.2 and has old Continuation.
This change might be reverted once stdlib will be rebuilt with LV=1.3
NB: kotlin.suspend doesn't need to be intrinsified since it only returns
its parameter with checkcast to kotlinin.jvm.functions.Function1
(i.e., it doesn't refer the coroutines package)
#KT-24861 Fixed
The call to `createTopLevel` instead of `create` (which creates
serializers for outer classes properly, with correct type parameter
contexts) caused MetadataSerializer to write type parameter metadata
incorrectly. For example, in the following case:
class A<E> {
inner class B<T, E> { ... }
}
A's type parameter E would get id 0, and B's type parameters T and E
would get ids 0 and 1. This is a problem because ids are supposed to be
unique for each class including its outer classes, and deserializer,
decompiler and stub builder rely on this assumption.
JVM metadata is unaffected because `create` is called correctly there,
see MemberCodegen#generateKotlinClassMetadataAnnotation
#KT-24944 Fixed
NB in FE unsigned integer constants are now represented using signed
integer types (e.g., UInt constant actually holds an Int value).
So, in IR so far we also represent unsigned constant literals as
constant values of corresponding signed types, but with corresponding
unsigned type:
0xFFFF_FFFFu becomes 'CONST Int type=kotlin.UInt value=-1'
Namely, check that when one calls a restricted function
the reciever used for that calls is obtained exactly from the enclosing
suspend function
#KT-24859 Fixed
If a type alias is used to reference an object (companion object) as a
qualifier, record FakeCallableDescriptorForTypeAliasObject in
REFERENCE_TARGET. This tells IDE that type alias was used in the file,
thus, if it's imported, such import isn't redundant.
REFERENCE_TARGET is used mostly by IDE and by ClassifierUsageChecker,
which we also have to update to handle qualifiers with
FakeCallableDescriptorForTypeAliasObject in REFERENCE_TARGET.
Rewrite some parts of ClassifierUsageChecker for cleaner interaction.
#KT-21863 Fixed Target versions 1.2.40
Hack: callee expression for when with subject variable is the subject
variable declaration. This solves the problem that all sub-calls in the
expression are implicitly considered to have a single common lexical
scope (and 'when (val x = ...)' introduces a new lexical scope, which
contains 'x').
Denis Zharkov