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'.
* 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
When compiler test was run before Intellij tests,
KotlinCoreEnvironment set the 'idea.plugins.compatible.build'
system property to '171.9999', which then prevented
Kotlin plugin from loading in Intellij tests (so all these tests failed),
because Kotlin plugin has 'sinceBuild' set to '172.1'.
The problem in KT-19833 is caused by the fact that the application
environment instance is shared between consecutive runs of the compiler
in one Make action (KotlinCoreEnvironment.ourApplicationEnvironment).
If the JDK 8 module is compiled first, the created application
environment has no JRT file system, and once the JDK 9 module is
compiled later, that environment is not recreated and thus classes from
JDK 9 are unresolved.
To mitigate this, split the CoreJrtFileSystem implementation into the
file system itself which is global per application, and CoreJrtHandler
which is bound to a particular JDK home location. CoreJrtVirtualFile
paths now consist of the path to the JDK home, the "!/" separator, and
the path to the file itself, e.g.
"/usr/lib/jvm/java9!/modules/java.base/java/lang/Object.class". The
implementation is inspired by CoreJarFileSystem & CoreJarHandler.
No tests added because the application environment is _not_ shared in
tests. Also, a JDK 9 module is going to be added to the Kotlin project
soon, and that will serve as a test
#KT-19833 Fixed
Rename addDeclarations -> registerModuleComponents
Use it to provide SamWithReceiverResolver extensions instead
Post construction on container composition can be achieved
but manually inserting injections where it seems appropriate
is bug prone
This fixes a bug where SamWithReceiverPlugin extension was not registered
for some containers in IDE which led to incorrect highlighting in IDE
Add IDE test for applying SamWithReceiver plugin
#KT-18062 Fixed
Also, require users of K2MetadataCompiler to pass "-Xmulti-platform"
manually. Gradle and Maven plugins already do that, so only users who
invoke kotlinc directly are going to be affected by this
#KT-19287 Fixed
* 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
Note that the history file name was changed (.kotlin_history ->
.kotlinc_history) because the history is now stored in a different
(incompatible) format.
#KT-11369 Fixed
Dmitry Petrov