This flag is used internally by EffectSystem as a sign of compiling
stdlib. If this flag is present, then EffectSystem will read contracts
on functions and serialize them into metadata even if corresponding
LanguageFeatures are turned off. This is done solely for building
1.2-runtime with contracts in it without the need to turn on
LanguageFeatures manually.
======
This commit finishes a first series of commits related to effect
system. After it, compiler is ready to work with contracts, but it is
impossible to actually annotate anything, because there are no
contracts DSL in stdlib yet.
Three modes:
- 'disable' (default): normalize constructor calls in coroutines only
(required because uninitialized objects can't be stored in fields),
don't insert additional code for forced class initialization;
- 'enable': normalize constructor calls,
don't insert additional code for forced class initialization;
- 'preserve-class-initialization': normalize constructor calls,
insert additional code for forced class initialization.
In case of partial/incremental compilation, a module usually consists of
two roots, one of which is source and another is binary. Thus, it's
incorrect to divide modules into "binary" and "non-binary", and only
look for .class files in "binary" modules in
CliJavaModuleResolver.findJavaModule. The more correct way is to think
of a module as a collection of roots, and every root is either binary or
source
The main changes are in jvm_package_table.proto and ModuleMapping.kt.
With JvmPackageName, package parts can now have a JVM package name that
differs from their Kotlin name. So, in addition to the old package parts
which were stored as short names + short name of multifile facade (we
can't change this because of compatibility with old compilers), we now
store separately those package parts, which have a different JVM package
name. The format is optimized to avoid storing any package name more
than once as a string.
Another notable change is in KotlinCliJavaFileManagerImpl, where we now
load .kotlin_module files when determining whether or not a package
exists. Before this change, no PsiPackage (and thus, no JavaPackage and
eventually, no LazyJavaPackageFragment) was created unless there was at
least one file in the corresponding directory. Now we also create
packages if they are "mapped" to other JVM packages, i.e. if all package
parts in them have been annotated with JvmPackageName.
Most of the other changes are refactorings to allow internal names of
package parts/multifile classes where previously there were only short
names.
In Kotlin 1.1 and before, there were no nullability assertions on
extension receivers, because receiver is resolved with NO_EXPECTED_TYPE.
So, if an expression of platform type is passed as an extension receiver
to a non-private function, it would fail with IllegalArgumentException.
However, if the function is private, then we generated no parameter
assertions under assumption that such function can be called from Kotlin
only, and all arguments are checked on the call site. Thus 'null' could
propagate indefinitely.
In Kotlin 1.2, we do the following:
- Generate nullability assertions for expression receivers.
NB nullability assertions are stored for ReceiverValue instances, not
for expressions: given expression can act as receiver in different
calls, each with an expected receiver type of its own.
- Generate nullability assertions for extension receivers of private
operator functions.
NB it still can throw NPE for some particular "optimized" cases, but at
least those nulls would not propagate indefinitely.
This behavior is disabled by an "advanced" command-line option
'-Xno-receiver-assertions'.
* Plugins for JS CLI compiler now can be loaded via -XPlugin option
* New extension point in project
* JS translator modified to accept synthetic declarations and call
extension.
* Some functions made public to create a small API
Sergey Igushkin