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
Exposing this property causes IDEA to treat it as a free
command line argument, which is undesirable.
Support source roots via setting command line arguments inside
JS gradle task.
Invalid compiler arguments should lead to a compilation error, not
internal error. This has been fixed by splitting the
"parseArguments(...)" call (which does parsing + validation) in
CompileServiceImpl into two calls of parseCommandLineArguments +
validateArguments, and returning with a compilation error if the latter
did not succeed
#KT-16057 Fixed
#KT-14848 In Progress
Before the change, Gradle always explicitly set language and api
version to the latest version, preventing the compiler
from inferencing the arguments.
#KT-18047 fixed
Alexander Podkhalyuzin