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
The inliner uses module descriptors to figure out if it needs to
regenerate objects.
We should avoid the use of descriptors in the inliner, but this
works as a first quick fix.
Svyatoslav Scherbina