To prevent confusing shortcuts defined on `KotlinTargetsContainer`
when declaring a KotlinTargetHierarchy:
e.g.
```kotlin
kotlin {
targetHierarchy.default {
common {
ios() // <- [DSL_SCOPE_VIOLATION]
//'fun ios(): Unit' can't be called in this context
// by implicit receiver. Use the explicit one if necessary
}
}
}
```
^KT-53570 Verification Pending
If string concatenation contains object value, then this argument
will not have explicit toString call. We must find and check toString
method manually.
#KT-54615
fix(KT-54480): exclude default from the regular reserved keywords to give ability to export intities with default export.
Merge-request: KT-MR-7459
Merged-by: Artem Kobzar <Artem.Kobzar@jetbrains.com>
Only when dependencies contain kotlin-stdlib-1.8+ dependency. Such
substitution could be disabled via 'gradle.properties' by adding 'kotlin
.stdlib.jdk.variants.substitution=false'.
^KT-54136 Fixed
These should only have ever been necessary for field type inference in
coroutines, which should have been fixed by 0fc676a20c.
Unlike 903a5d69a4, this time the change is in an optimization pass.
Advantage: optimization passes have a closer to the JVM view of the
bytecode, which makes this change significantly more likely to be correct.
Disadvantage: technically we don't really guarantee optimization passes
other than FixStack will run at all. For KT-54581 this is 100% fine
since the problem itself is caused by redundant checkcast elimination in
the first place (otherwise there would've been a redundant cast to
String), but for KT-53146 this means the fix is somewhat incidental and
not necessarily guaranteed.
^KT-53146 Fixed
^KT-54581 Fixed
* Depend on kotlin-compiler project instead of its runtimeElements only
* trove4j fixes: add as a dependency and use common version
* Strip dependencies in different projects: remove unnecessary
FastJarFS was behaving differently than the regular CoreJarFS it
tries to replace, namely it was cleaned after each compilation
(had the lifetime tied to core env).
This commit preserve it in the app env the same way as CoreJarFS,
so it could be reused in parallel builds and preserved if automatic
cleanup of the app env is turned off,
But since FastJarFS caches also mmf handles, the additional handles
cleaning is introduced that triggers after all possibly parallel
compilations are finished.
Lazy computation in publication mode may lead to running of init code
many times in parallel, and it actually happens in IDE.
Instead, we stick to the option which is used for lazy computations
all across compiler code.
sebastian.sellmair