These tests don't work on JVM target 1.6 after 6d664bcd10 because we're
generating `Boolean.compare` which is only available since 1.8. (It is
not a big deal because JVM target 1.6 is prohibited for users now.)
It's incorrect to take the first parameter type from the expression
itself because it can be nullable if smart casts are used. And if it's
nullable, it's mapped to the wrapper type and calling
`comparisonOperandType` for it makes no sense. Instead, take the type
from the callee function, as it's guaranteed to be mapped to a JVM
primitive type.
E.g. in `test1` function in the added test, the problem was that the
dispatch receiver type of the call expression is `Double?`, which is
mapped to `java/lang/Double`, whereas we clearly wanted to obtain the
primitive `D` (double) type.
#KT-52163 Fixed
Node.js support already use 16.13.0.
Probably it's useful to use default version for dogfooding propose,
Likely it's cover small cases, but at least could help to catch some
platform dependent issues.
If we need some specific (likely newer) version of node somewhere
in the project it's better to specify it for specific parts and
consider updating version of node inside gradle support and revert
a change.
For negative case, throwing CCE, we already have the issue KT-8135
and dedicated tests:
* genericDelegateUncheckedCast1.kt
* genericDelegateUncheckedCast2.kt
Related issues: KT-8135 KT-39588 KT-48749 KT-49837
Unit materialization for IrCall is required for operations with dynamic type.
However it produces useless Unit_getInstance() calls,
especially in return expressions. The pach also adds some heuristics
for reducing the amount of Unit_getInstance() calls from return expressions:
do not add Unit_getInstance() if return value has Unit type.
Relaited to KT-51139
^KT-23252 Fixed
scripting-dependencies-maven actually depended on both maven.resolver
and Aether dependencies, it caused an issue in KScript
(https://github.com/holgerbrandl/kscript/issues/345) and caused some
issues in the past. These problems were partially solved with exclude()
which is now removed.
Originally, the classpath-snapshot output directory was:
1. <project>/build/kotlin/<task>/classpath-snapshot for KotlinCompile
2. <project>/build/tmp/kapt3/classpath-snapshot/<source-set> for
KaptGenerateStubsTask
In commit 1d1c6d5, we started using location 1 for both tasks for
consistency.
Around that time, commit 46cb490 had a merge conflict with the above
commit, but the conflict resolution was not correct yet:
- The property was set twice, causing a build failure.
- Location 2 was set for KaptGenerateStubsTask again.
This commit fixes both issues, so that:
- The property is set only once.
- Location 1 is used for both tasks.
Test: Added Kapt3IT.testSimpleWithIC_withClasspathSnapshot to prevent
regression
^KT-52187 Fixed
This commit fixes:
Caused by: java.lang.NoClassDefFoundError: com/intellij/openapi/components/ComponentManager
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:555)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:458)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:452)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:451)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3166)
at java.base/java.lang.Class.getMethodsRecursive(Class.java:3307)
at java.base/java.lang.Class.getMethod0(Class.java:3293)
at java.base/java.lang.Class.getMethod(Class.java:2106)
at org.jetbrains.kotlin.config.JpsUtilsKt$isJps$2.invoke(JpsUtils.kt:17)
In c1f2d66ed8 I replaced
`ApplicationManager.getApplication() == null` with
`Class.forName("ApplicationManager").getMethod("getApplication").invoke(null)`.
It turned out that those two are not equivalent.
`getMethod` tries to match queried signatures with existing signatures
=> it tries to load classes in signatures => it tries to load
`com.intellij.openapi.application.Application` (and fails because
`Application` supertype isn't in the classpath).
Contrary, `ApplicationManager.getApplication() == null` doesn't try to
load `com.intellij.openapi.application.Application` class, so it doesn't
fail.
I use MethodHandles API because it forces me to write `Class.forName`
myself (compared to implicit `Class.forName("Application")` inside
`getMethod`) which I find a nice safety feature.
This makes the debugger update the values when entering a recursive
call, and also uses fewer variable slots.
This may also work on the JS backend, but Native would probably require
something else.
^KT-47203 Fixed
`$$forInline` functions do not pass through the state machine generator,
and optimizing `Ref`s before that changes how assignments inside lambdas
passed to `suspendCoroutine`, etc. behave: without a `Ref`, the
assignment is not reflected in the continuation object, so the variable
has old value on resumption.
These functions will be optimized later, after they are inlined
somewhere and the state machine is generated.
^KT-52198 Fixed
E.g. in `x + f()` where `f` is an inline lambda, the instructions for
`+` should have the line number of that expression (while previously
they instead had the line number of the last line of the lambda).
^KT-51738 Fixed
Alexander Udalov