- Calling suspend functions is allowed
- Presence of suspend function type still makes declaration
unusable unless it belongs to a value parameter as a top-level type
containing less then three parameters
Still, warning should be emitted because they will become unsupported in 1.4
#KT-25683 In Progress
This is still not 100% foolproof because one may place such a
requirement manually on a suspend function (with `@RequireKotlin`, for
example), which will trick the compiler into thinking that this is a new
suspend function, even if it was compiled with old coroutines. But it's
still better than only checking the version number
Instead of adding new kind of types, we'll use flag to disambiguate
usual types from unsigned ones, this approach has two advantages:
- less changes in the metadata format
- it allows naturally extend format for unsigned arrays,
which will be supported later
#KT-25310 Fixed
#KT-25273 Fixed
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
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
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
The standard way of loading resources with built-ins metadata from the
current class loader no longer works in the modular mode on Java 9
because the current class loader is for module 'kotlin.reflect', but the
metadata is located in the module 'kotlin.stdlib'. On Java 9, we now use
the class loader of 'kotlin.stdlib' to load these resources.
#KT-21266 Fixed
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
- Introduce new language feature 'ReadDeserializedContracts', which
allows to deserialize contracts from metadata.
- Introduce new language feature 'AllowContractsForCustomFunctions',
which allows reading contracts from sources.
- Use new features instead of combination 'CallsInPlaceEffect ||
ReturnsEffect'
- Rename 'CallsInPlaceEffect' -> 'UseCallsInPlaceEffect',
'ReturnsEffect' -> 'UseReturnsEffect'. As names suggest, they control
if it is allowed to use corresponding effect in analysis.
We have to introduce separate 'ReadDeserializedContracts' to enable
contracts only in some modules of the project, because libraries are
read with project-wide settings (see KT-20692).
Object model for deserialized protobuf isn't very cheap, so
loading just our stdlib's packages several times (as we do in the IDE)
might lead to ~ 96 MB of retained memory just by these objects.
While in fact many of them remain unused
#KT-21517 Fixed
Only store the ClassId of the enum class and the Name of the entry, and
resolve the needed descriptor in getType() instead, which now takes the
module instance where that descriptor should be resolved
Remove KotlinBuiltIns and take a ModuleDescriptor instance in getType
instead. This will allow to create constant values in contexts where
there's no module or built-ins accessible (such as, deserialization of
module annotations during indexing of .kotlin_module files in IDE).
Note that some values (KClassValue, EnumValue, AnnotationValue) still
take module-dependent objects (KotlinType, ClassDescriptor and
AnnotationDescriptor respectively). This is to be refactored later
Denis Zharkov