Previously (few commits earlier), it contained two versions
of receiver (lhs) generated separately for each desugaring version
that looked a bit redundant.
Now, at FIR building stage we just don't create desugaring sub-trees,
instead they are being built during bodies transformation and that seems
to be much convenient there, since we don't need to reverse-engineer
get-set-operator version to check if containing calls are successful
(as we just built those calls and retain them)
Semantically, this changes may only change how data flow works
for such statements (see changed compatibilityResolveWithVarargAndOperatorCall.kt)
^KT-50861 Relates
It's necessary to allow a?.b += v be interpreted as a?.(b += v)
But currently FirAssignmentOperatorStatement is not FirQualifiedAccess
^KT-41034 In Progress
Static inline class replacements are possible only in inline classes.
Iterating over class declarations here took ~0.5% of backend time on
average projects, and up to 4% of total compilation time on degenerate
projects such as the one in KT-20055.
Before this commit we took just first intersection member for this check.
However it's quite bad, because we were dependent on supertype order.
Choosing the most specific member looks more consistent here.
#KT-50969 Fixed
to ensure precision (otherwise, rounding errors to milliseconds may
add up and cause unexplainable gaps in the running time).
We can still use milliseconds in the final report after all the precise
sub-build-times have been aggregated.
Don't remove the temporary KONAN_DATA_DIR because it might be still in
use by the Gradle daemon process.
Create a new temporary directory instead.
The tests were introduced in 544447e...fa951f8
Caching is wrong when this code is running in Gradle daemon, because
the daemon can change the environment, while localKonanDir depends on
the environment.
Use-site substitution override happens in situations like this:
```
interface List<A> { fun get(i: Int): A }
fun take(list: List<String>) {
list.get(10) // this call
}
```
We want to have those overrides unwrapped, because we don't want
to deal with a different KtSymbol for each possible use-site
^KT-50862 Fixed
If the class `A` is in a jar `previous.jar`, the following CLI
invocation will take that class instead of the `A` class
defined in `A.java`:
kotlinc -cp previous.jar A.java B.kt
This is problematic for build tools that put the jar for a
previous build on the classpath when recompiling some of the
files.
^KT-51025 Fixed.
Denis.Zharkov