This annotation is currently internal because we only commit to its
support for our own libraries. It will be used to change JVM package
names of declarations in JDK-specific stdlib additions (now called
kotlin-stdlib-jre7/8), both to preserve source compatibility of the old
Kotlin code and to solve the split package problem (KT-19258)
Before this change, we were computing the visibility of an inherited
private property setter, and ISE at AsmUtil.getVisibilityAccessFlag
happened ("invisible_fake is not a valid visibility in backend")
Header/impl declarations are now considered fully compatible even in the
case when the impl declaration has no "impl" modifier. The error about
no "impl" is now reported separately and only on the impl declaration,
never on the header declaration
#KT-20087 Fixed
Enum entries are "special" kind of singletons that should be
referenced as a captured 'this' instance inside during entry
initialization, because corresponding static fields in enum class
are not initialized yet.
#KT-7257 Fixed
Use it for char boxing/unboxing and unit materialization.
Possible to use for other purposes, for example, to add type checks
to dynamics.
See KT-18793, KT-17915, KT-19081, KT-18216, KT-12970, KT-17014,
KT-13932, KT-13930
In an inner class of the enum entry class, enum entry reference should
be generated as an outer 'this', not as a enum entry access, because
enum entry itself may be not initialized yet.
- Tell user what exactly is not supported (e.g., local inline function)
- Reduce diagnostics range to a keyword or an identifier
where appropriate
#KT-16223 Fixed Target versions 1.1.50
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
Alexander Udalov