Previously, it was obtained from expected type of a variable being assigned,
but it's better to use the type of resulting expression
Initially this part was brought in 4ab0897d7d,
but as we see in commit message and tests it was all about unit-coercion
Kotlin's compilation task outputs usually contains a lot of small files,
which is not so performant to copy as-is into new location. In this
change coping was replaced by using zip archive with no compression.
From my test I see around 2x performance improvement on doing task
outputs snapshot.
Further optimizations will be done via separate issue as they are
non-trivial and requires some changes on the compiler side.
^KT-49782 Fixed
Avoid adding ConfigurableFileTrees to sources as that causes
individual *.java files to be evaluated as sources roots. To
pass the dependency info, manual dependsOn is used, but in the
future SourceRoots should be fixed to carry the dependency info.
The implementation was keeping delayed jobs in std::set sorted
only by the scheduled execution time (in microseconds since epoch).
So two jobs submitted to a worker and having the same scheduled time
were considered equivalent by the set, and one of them got lost.
Fix this by using std::multiset instead of std::set.
If compiler plugin removes source files between rounds of incremental
compilation, it may result into incorrect state of stubs. But rebuilding
stubs may require services available in UI mode only and cause
compiler failure.
This commit contains work-around allowing to avoid incorrect state of
stubs.
#KT-49340 Fixed
Not publishing this attribute fixes the consumers that don't set it.
Those may encounter either a conflict of Kotlin <= 1.5.31 rule on
{JVM, Android} -> Android vs Gradle rule
{standard-jvm, android} -> standard-jvm (causing disambiguation
failures). Or they may run Gradle < 7.0 which doesn't have
disambiguation rules for `org.gradle.jvm.environment` and therefore
treats it as an ordinary extra attribute, thus eventually preferring
variants which don't have it if no other disambiguation rule worked
(again causing disambiguation failures since some rules may prefer the
variants where this attribute *is* set).
Also set a "non-jvm" value of this attribute for non-JVM variants for
project-to-project dependencies in order to "align" them so that Gradle
doesn't prefer variants not marked with this attribute.
Extend the set of dependency resolution tests which check
compatibility of different kinds of Android & JVM consumers against
project and published library: add Kotlin 1.5.31 consumers, also check
consumption with different Gradle version than the one which did the
publication.
Issue #KT-49835
In the IDEA plugin update there are a code that used system property
"idea.plugins.compatible.build" to calculate the IDEA version
that will be sent to plugin marketplace to download last version of
the plugins. It seems like by some reason setupIdeaStandaloneExecution()
was called from the IDEA thread and because of that idea version was
calculated incorrectly and incorrect version of the plugins was
downloaded.
It is still unclear how the setupIdeaStandaloneExecution() could be
called from the IDEA, so added logging for that.
Relevant issue: MP-3702
Relevant code in the IDEA:
- ApplicationInfoImpl.getPluginsCompatibleBuildAsNumber
Denis.Zharkov