to ensure binary compatibility with stdlib inside IntelliJ.
This includes using the latest stable kotlin API version and
forbidding using experimental declarations from stdlib.
^KT-62510
Existing tests were k1-only in CI. Simplified test project, added
assertions for native. Switched to the new test Dsl.
^KT-61845 duplicates KT-61590
^KT-56963 in progress
Merge-request: KT-MR-12651
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
^KT-62656 Fixed
I blindly converted all `@AllowDifferentMembersInActual` to suppresses.
But some suppresses in stdlib are redundant. I'm too lazy properly
annotate only the necessary places. All these suppresses will go away
after the bootstrap update anyway
I drop allowDifferentMembersInActual_class and
allowDifferentMembersInActual_typealias tests because their only purpose
was to check that `@AllowDifferentMembersInActual` works as expected
Note: some tests are failing in the compiler because of that. I will fix
them in the next commit
Having a dedicated konan data dir is not working well on Windows
machine. Since invocation of kotlin compiler would make JVM
to load native-specific dlls and it would not be possible to clean them
up until they are unloaded.
^KT-61359 Verification Pending
In commit 5ceebec, the MemoizedCallable instance was created inside the
Provider, which means that the MemoizedCallable is not reused the next
time the Provider is resolved. This was not the intended effect.
In this commit, we will create the MemoizedCallable instance up front so
that each time the Provider is resolved, it will reuse the same
MemoizedCallable and therefore avoid recomputing the value.
Test: Manually verified on the large project in KT-62496
^KT-62496 Fixed
Currently, the performance overhead when loading a Gradle property
consists of:
1. Creating a Provider
2. Resolving the Provider
Both steps are performed even when the same property was loaded before.
That means this overhead will multiply when there are a large number of
property read requests (e.g., in KT-62496, the tested project 400,000
read requests for only 17 properties).
To improve performance, we will now cache both steps with a
BuildService.
With this commit, configuration time for the tested project returns to
the same level before commit d6becee where the performance regression
happened (that commit can't be reverted because it introduced
`Provider`s which are required for proper Gradle usage).
Test: Manually verified on the large project in KT-62496
^KT-62496 Fixed
It is not obvious from 'KotlinSingleTargetExtension' that calling
into 'target' is unsafe and it might throw.
Ordering code (especially with Android) is hard:
It is not clear when the target will become available.
The Future (and forAllTargets implementation) is intended
to make working with targets generically more safe.
KT-61634
Ilya Kirillov