Note that there are some other problems, for example:
`val a = if (true) 1 as Number else 2`, here we'll get useless cast
#KT-9551 Fixed
#KT-9645 Fixed
#KT-11916 fixed
To use the IC either:
1. set the `kotlin.compiler.incremental` property to `true` in a pom.xml:
```
<properties>
<kotlin.compiler.incremental>true</kotlin.compiler.incremental>
</properties>
```
2. pass the `kotlin.compiler.incremental` property in a command line:
```
mvn install -Dkotlin.compiler.incremental=true
```
When IC is on Kotlin plugin is expected to print the warning in the log:
```
Using experimental Kotlin incremental compilation
```
After each call an incremental compiler will also log how many files it has compiled:
```
Compiled %SOME_NUMBER% Kotlin files using incremental compiler
```
Note that the first build will be non-incremental.
For more diagnostic information (such as an exact list of compiled files) use the `kotlin.compiler.incremental.log.level` system property:
```
mvn install -Dkotlin.compiler.incremental=true -Dkotlin.compiler.incremental.log.level=info
```
To force the rebuild just run the 'clean' goal:
```
mvn clean install
```
xercesImpl was unnecessarily added to the compiler uberjar during migration
to the idea platform 171. This caused NCDFE about classes from org.w3c
package.
And to simplify application of this commit and to ensure that only required
jars are packed into the uberjar, the build.xml was altered to use
explicit list of the jars from the ideaSdk/core directory, rather than
a mask.
Fixes #KT-17143 and #KT-17157
(cherry picked from commit 5595bea)
A critical bug related to Java 8 bytecode (default/static methods in
interfaces) was fixed in maven-shade-plugin in 3.0.0, which reproduces
for kotlin-compiler-embeddable on Java 9 because the verifier in Java 9
started to check consistency of constant pool references to methods in
interfaces
#KT-17112 Fixed
PathUtil.getJdkClassesRoots() takes the path to the JRE. On macOS, this
is the same as the path to the JDK (for Java 6), so the test worked
there. However for OpenJDK on Linux, there's a separate directory named
"jre" in the JDK root. See JavaSdkUtil.getJdkClassesRoots for more
information on how the JDK roots are found
As "java" does, do not include the current directory to the classpath if
the explicit classpath is specified. This is more stable than always
adding the current directory, and users can easily add the ".:" to the
beginning of the explicit classpath themselves
#KT-17100 Fixed
Mikhail Zarechenskiy