Scopes may return private symbols from
supertypes, they should not clash with
symbols from the current class.
For example, see:
`FirLightTreeBlackBoxCodegenWithIrFakeOverrideGeneratorTestGenerated.FakeOverride#testPrivateFakeOverrides1`
Lombok shouldn't generate functions if the
user has defined explicit ones.
In K1 generated functions are not really
added to the declared members scope.
^KT-61243 Fixed
Metadata compilation with name "main" isn't used in Hierarchical
Multiplatform. It used to compile commonMain source set to legacy
metadata artifacts. With Hierarchical MPP common source sets start
to compile to klib metadata.
GranularMetadataTransformation.ProjectData is created for all projects
There was a chance when it is created too early before some projects
evaluation. And if that happened that these projects contained some
subplugins (for example KSP) that add more source sets. Then old
algorithm of collecting sourceSetsMetadataOutputs() would fail with
ConcurrentModificationException. For example in this scenario:
Lets assume we evaluate sourceSetsMetadataOutputs for project with
just one common source set: commonMain.
And therefore one metadata compilation whose default source set name is:
commonMain.
On top of that a subplugin applied to this project. This subplugin
creates additional source set for each metadata compilation.
Then with old algorithm following would happen:
* start iterating over sourceSets
* for `commonMain` source set await its Metadata Compilation
* * When Metadata Compilation gets configured at some point of time
it will reach KotlinCommonSourceSetProcessor.doTargetSpecificProcessing
method. Which will apply subplugins.
* * When subplugin is applied it adds a new Source Set to
the sourceSets collections: CME is occurred!
Adding a source set in subplugins should be regulated
either allow it and fix related side effects OR deprecate it.
The current fix doesn't solve all potential issues with adding new
source sets from subplugins. It primarily focused on CME occurrence
for the case above.
^KT-62299 Verification Pending
This commit is literally this shell command:
```
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/AbstractExpectActualAnnotationMatchChecker.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1AbstractExpectActualAnnotationMatchChecker.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/AbstractExpectActualCompatibilityChecker.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1AbstractExpectActualCompatibilityChecker.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/ExpectActualCollectionArgumentsCompatibilityCheckStrategy.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualCollectionArgumentsCompatibilityCheckStrategy.kt
cp core/compiler.common/src/org/jetbrains/kotlin/resolve/multiplatform/ExpectActualCompatibility.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualCompatibility.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/ExpectActualMatchingContext.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualMatchingContext.kt
cp core/compiler.common/src/org/jetbrains/kotlin/resolve/multiplatform/ExpectActualMemberDiff.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualMemberDiff.kt
```
Motivation: KMP is going to evolve in K2 a lot. But we don't want to
touch K1 version of KMP. That's why it's easeir to just copy-paste
expect-actual matcher into K1 flavor
There's no module kind check for IDE at the moment: IDE modules don't
have access to compiler arguments or configuration. K1 currently doesn't
report the diagnostic either. See KTIJ-27279 for more details.
This commit repeats K1 behaviour: K2 IDE won't fail because of the
missing service, but the diagnostic won't be reported in IDE, only
during compilation.
KT-61615
it's useful for IDE's features such as write UAST or refactorings
^KT-62302 fixed
Merge-request: KT-MR-12414
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
When computing the conversion type for a type operator call, the
argument needs to be fully unwrapped before getting the resolved type.
This avoids the situation when the argument is a when-subject and the
assumed original type is not correct. Before, only smart-casts were
unwrapped, and this change will also unwrap when-subjects (as well as a
few other FirExpressions).
^KT-62114 Fixed
There are conditions where the data-flow analysis for a control-flow
graph node is delayed. Make sure that when completing a graph, all nodes
within the graph have completed their data-flow analysis.
^KT-61794 Fixed
Nikolay Lunyak