The traditional way to get a 'FirTowerDataContext' in K2 was to
reparse the callable body and pass it through all resolution phases.
It is terribly inefficient and requires a lot of magic.
Currently, 'ContextCollector' is only going to be used to collect
a code fragment context. After proper test coverage and a plenty of
patches it's going to become a generic replacement for read-only
on-air resolution.
Some native test dependencies were excluded from JPS import of `:kotlin-atomicfu-compiler-pligin`
Merge-request: KT-MR-11477
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Now the multiplatform extension exposes compiler option DSL for common
compiler arguments. This compiler option synced as a convention for
targets compiler option.
In the case of Kotlin source sets which are not used as defaultSourceSet
in compilations - extension compiler options are synced as convention
into those.
^KT-57292 In Progress
Experiments with the DefaultKotlinCompilationAssociator where made
during KT-60937. One experiment broke running functionalTests in
kotlin.git in bootstrap mode. This case was not yet covered by
CI.
^KT-60937 Verification Pending
As it might happen, that the configure code could be triggered
too early, capturing the state of 'runtimeDependencyFiles' to early as well.
^KT-60937 Verification Pending
The IdeBinaryDependencyResolver will filter respective
files by using a simpler check: testing if the files
do reside within the build dir of the current project.
^KT-60937 Verification Pending
The new ld from Xcode 15 incorrectly parses a simulator
target version if it is below the minimum supported version.
It is unclear if this is intentional or not, but we have to play
by Apple's rules. Anyway, 9.0 is quite obsolete, so this change
should be pretty safe.
^KT-60758
In preparation for KT-58531, LL FIR resolvers need to support resolving
FirFiles. This change has a very large impact on test data, so it is
being made separately.
To get to the proper qualified expression, we need to unwrap the outer
`FirVariableAssignment` if we deal with the property access inside of
assignment expressions
^KT-60954 Fixed
This change prevents going up the scopes once we find a
substitution override. Whatever we'd find by going further is not
going to be a direct overridden anymore, so it would lead to incorrect
results when collecting direct overridden-s. Without this change, we get
error modules in FT intellij.
Consider the following example from
`extensionLambdasAndArrow.kt`:
```
val x4: String.() -> String = if (true) {
{ str: String -> "this" }
} else {
{ str: String -> "this" }
}
```
Because of
`coerceFirstParameterToExtensionReceiver`
the given lambdas must be of the type
`String.() -> String`, but because of a bug
they are `String.(String) -> String`. At the
same time, during inference their expected
types are, indeed, calculated correctly as
`String.() -> String`.
^KT-59394 Declined
(no more compiler crashes, #potential-feature)
Yan Zhulanow