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 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'.
* Support flags with any value (not just Boolean)
* Support all flags by parsing arguments in KotlinFacetSettings, instead
of manually listing known flags
#KT-19210 Fixed
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
Ensure that messages reported on a file but with no line information are
reported before diagnostics related to code. This fixes
Java9ModulesIntegrationTest.testSeveralModulesWithTheSameName on some
machines
Dmitry Petrov