multiple unnamed arguments represented as value named expression with array initializer
call kind for array in annotation argument should be "array initializer" instead of "method call"
#KT-16600 Fixed Target Versions 1.1.5
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'.
Generate synthetic accessors for property accessors only if the
corresponding methods are accessible in the current context.
#KT-19306 Fixed Target versions 1.1.5
* 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
For sake of working without jsr305.jar in the classpath `resolveTypeQualifierAnnotation`
may return javax.annotation.CheckForNull (although the latter is nickname itself)
#KT-19985 Fixed
In the case the single parameter of override has `Integer` type instead
of `int` type (while in common case it would be just `int`)
See the comment inside forceSingleValueParameterBoxing for clarification
#KT-19892 Fixed
Lateinit local vars are guaranteed to be non-null after store.
So we mark such stores as storing non-null value
(could be useful for some other constructs, too),
and optimize null checks accordingly.
Dmitry Jemerov