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
This commit ensures all the conversions inside the lambda expression
use the correct tree reference.
Otherwise, the problem arises in the
`toFirSourceElement()` call: if called form inside the
ExpressionsConverter, everything is OK, but calling it from inside
DeclarationsConverter will result in the wrong source text range.
This happens, because during the lambda expressions conversion a custom
ExpressionsConverter is created with the `lambdaTree` tree, but the
DeclarationsConverter continues to use the previous tree.
[JS IR] Add test with exported overridden property from interface
[JS IR] Accessors should not be exported when overridden from non-exported interface
Merge-request: KT-MR-6166
Merged-by: Ilya Goncharov <Ilya.Goncharov@jetbrains.com>
^KT-52144 fixed
but only explicitly. This does not fix a breaking change described in
#KT-52120, because it seems the correct behavior, but it allows
to "workaround" the problem by specifying nullability explicitly.
Also improve handling of nullable bindings in JSR-223.
#KT-49173 fixed
#KT-51213 fixed
Ilya Kirillov