Remove manual up-to-date checks that were preventing task
from being retrieved from the build cache. When outputs are
not present, task would always run because of
https://github.com/gradle/gradle/issues/9095.
Test: CommonizerIT
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
Jinseong Jeon