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
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.
It's necessary for generic inline suspend as a codegen
for it uses binding slice SUSPEND_FUNCTION_TO_JVM_VIEW
to generate fake continuation parameter, so all the
descriptors that are used for body generation must be
obtained from the SUSPEND_FUNCTION_TO_JVM_VIEW
#KT-19528 Fixed
Otherwise, when completing all the unsuccessfull candiates,
resolution of each lambda-arguments starts repeatedly for each candidate
that leads to exponential time
NB: Changes in `completeArguments` are necessary because otherwise
nested lambdas will be analyzed twice:
once for the main resolved call, and then for all candidates
that again leads to exponential complexity
#KT-16672 Fixed
#KT-19457 Fixed
Note that the quick fix to implement header class works incorrectly when
that class has nested classes at the moment; this should be fixed
separately
#KT-15494 Fixed
#KT-18573 Fixed
Also support a quick fix to add 'impl' modifier (KT-18454), although it
doesn't work yet on classes because there's no error on them in the IDE
#KT-18087 Fixed
#KT-18452 Fixed
#KT-18454
Try to report most of the errors on the actual members of the impl
class. In many cases, there's a 1:1 mapping of header to impl class
members, so the error "some members are not implemented" on the class
declaration itself is redundant. Exceptions include functions/properties
from supertypes (there may be no other place to report a signature
mismatch error in this case), functions/properties not marked with
'impl' (the checker is only run for declarations explicitly marked with
'impl') and default constructors (the checker is not run for them)
#KT-18447 Fixed
Try to report most mismatch errors on the 'impl' declaration. Only
report a mismatch error on the 'header' declaration if no error would be
otherwise reported on any 'impl' declaration in the compilation unit.
Also render declaration kind in the message
#KT-18447 In Progress
In short, some of the bytecode analyzers assume that there could be
no stores instructions into parameter vars with value of different
types (even when the value type is a subtype)
See the issue for details
#KT-19713 Fixed
Dmitry Petrov