Collect module name properly from facets settings, using CLI arguments
which define module name ('-module-name' on JVM and Common,
'-output-file' on JS).
^KT-23668 Fixed
* SuccessOrFailure inline class is introduced
* Continuation.resumeWith(SuccessOrFailure)
* createCoroutineUnintercepted
* [Restricted]ContinuationImpl as named suspending function base
* [Restricted]SuspendLambda as suspending lambda base
* SuspendFunction[01] interfaces for efficient createCoroutine
* Serializable coroutine classes
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
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
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
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
Instead of IndexOutOfBoundsException from the protobuf internals which
was thrown when loading extension with a non-existing index out of the
list of all extensions (KT-23413)
Previously, inline suspend functions were effectively inline only,
but ordinary inline functions can be used as noinline.
To fix the issue, I generate two functions: one for inline with suffix
$$forInline and without state machine; and the other one without any
suffix and state machine for direct calls.
This change does not affect effectively inline only suspend functions,
i.e. functions with reified generics, annotated with @InlineOnly
annotation and functions with crossinline parameters.
#KT-20219: Fixed
It's only used for DeserializedPackageMemberScope that's being created
during initialization
At the same time, protobuf objects may be not very light-weight
(see 2e933a165a)
#KT-24513 Fixed
- DeserializedPackageFragmentImpl doesn't actually need member scope to be lazy
in a sense of optimization. It was only necessary for breaking
initialization cycle: DeserializationComponents <-> DeserializedPackageFragment
- For MetadataPackageFragment it might be useful to have
member scope actually lazy since it has O(n) complexity when n is a number
of package parts
This change is helpful for avoidance of storing reference to package-proto
#KT-24513 In Progress
Dmitry Savvinov