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 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'.
No package annotations are going to be loaded, and
TypeQualifierDefault/TypeQualifierNickname are no longer recognized by
default. Use the CLI argument "-Xload-jsr305-annotations" to enable this
behavior back
#KT-10942
E.g. "kotlinc foo.kt test/Bar.java" will compile foo.kt, and
declarations from Bar.java will be accessible to Kotlin code in foo.kt.
The change in AbstractTopLevelMembersInvocationTest is needed because an
incorrect configuration was created in that test where a library jar was
also a Java source root (the compiler is never configured this way in
production), which led to an exception in
JavaCoreProjectEnvironment#addSourcesToClasspath
#KT-17697 Fixed
In this mode, javac AST and Symbol files are used during
Kotlin compilation instead of PSI / binary stuff.
Later, they are reused for Java file compilation.
javac in this mode is integrated into kotlinc.
Friend modules should be provided using the -Xfriend-modules flag
in the same format as -libraries. No manual configuration required for
JPS, Gradle and Maven plugins.
Friend modules could be switched off using the -Xfriend-modules-disabled
flag. Doing that will
* prevent internal declarations from being exported,
* values provided by -Xfriend-modules ignored,
* raise a compilation error on attemps to use internal declarations from other modules
Fixes #KT-15135 and #KT-16568.
- Display the Kotlin version in kotlin-gradle-plugin. This is needed
because if "-version" is specified in compiler arguments, the "info"
level of the message printed by the compiler in CLICompiler prevents
it from being displayed by default (unless "--debug" is passed to
Gradle).
- Display the version of JRE the compiler is running on. This will be
helpful to diagnose Java 9 related issues in the future.
- In CLI, also display the executable name (kotlinc-jvm or kotlinc-js)