Case:
```
options.incrementalAfterFailure = false // assignment operator (a)
options.incrementalAfterFailure.set(false) // equivalent (without) (b)
// (a) works thanks to AssignResolutionAltererExtension
// 'incrementalAfterFailure' is a synthetic Java property
// i.e. getIncrementalAfterFailure()
// Navigation to 'incrementalAfterFailure' (a) doesn't work.
```
By navigation, we mean opening declaration sources. The reason of the
issue lied in sources absence (inability to find them).
In general, sources are available via declaration descriptor.
To find one for a property, one needs to understand expression
kind: read/write/both. Hence, the choice of a getter/setter/both.
Since `=` operator is interpreted as a write type expression, a setter
was searched. Missing one resulted in corrupted navigation.
As a fix we provide getter for the missing setter case.
^KT-56941 fixed
Some of our light classes have no correct parent (KT-56882),
so I temporarily disabled
AbstractSymbolLightClassesParentingTestBase for such cases
(previously decompiled light classes were not tested at all)
^KT-56613
^KT-56882
Previously, we queried heavy kotlin package provider two times which affected performance
Now it's being queries only a single time
Also, the commit introduces separation for KotlinPackageProvider between kotlin and platform-specific packages
^KTIJ-24640
Annotation arguments that are resolved in COMPILER_REQUIRED_ANNOTATIONS
phase are resolved again in ANNOTATION_ARGUMENTS phase. If they resolve
to a different symbol, report an error.
KT-56177
If an annotation doesn't specify an explicit use-site target,
previously it was added to both, the primary constructor value parameter
and the property in the FIR. Then, in FIR2IR, only the "correct" one was
added to the IR. Move up the deduplication logic into the frontend.
^KT-56177 Fixed
```
open class Base<T> {
fun foo(): T = ...
}
class Derived<T> : Base<T> {
override fun foo(): T = ...
}
```
In intersection scope of type `Base<T> & Other<R>` we should create
intersection override based on `Base.foo(): T` and `Derived.foo(): R`
at the same time, despite the fact that `Derived.foo` actually directly
overrides `Base.foo`
^KT-56722 Fixed
We do not need running IMPLICIT_TYPES_BODY_RESOLVE to check candidate applicability.
Additional resolve to IMPLICIT_TYPES_BODY_RESOLVE takes about 5% of completion time
^KTIJ-24640
Now all tests with `Fir` in name are named accordingly to parser which
is used in them -- `FirPsi` or `FirLightTree`. This is needed to keep
consistency between different types of tests, because there is no
single default in parser mode between different scenarios of using FIR
In K1, we have the rules like:
- if there's explicit type of a property, then use it
- if there's an initializer, obtain its expression-type
- Otherwise, use getter's return type
The case when getter's type is implicit is handled at
FirDeclarationsResolveTransformer.transformProperty
^KT-56707 Fixed
The commit is based on b09561c3c3
Co-authored-by: Dmitriy Novozhilov <dmitriy.novozhilov@jetbrains.com>
^KT-40904 Fixed
^KT-55177 Fixed
Review: https://jetbrains.team/p/kt/reviews/8731
True negative test already exist:
`compiler/testData/diagnostics/tests/multiplatform/hmpp/multiplatformCompositeAnalysis/intermediateWithActualAndExpect.kt`
In scope of KT-40904 KT-55177
Review: https://jetbrains.team/p/kt/reviews/8731
In order to make it possible to run hmpp tests with
`ENABLE_MULTIPLATFORM_COMPOSITE_ANALYSIS_MODE`, a dependency manager
must be implemented. This commit implements some basic dependency
manager. I'm not sure in its correctness because
`CommonDependenciesContainer` is an awkward API, but this dependency
manager works for my cases.
Why: I need hmpp + `ENABLE_MULTIPLATFORM_COMPOSITE_ANALYSIS_MODE`
infrastructure to cover `ExpectActualInTheSameModuleChecker` (I will add
the checker in the next commit) with tests. The checker couldn't be
covered with regular hmpp tests because regular hmpp tests and
`K2MetadataCompiler` run the compiler in a different way.
Contrary, `ENABLE_MULTIPLATFORM_COMPOSITE_ANALYSIS_MODE` runs the compiler in a
way `K2MetadataCompiler` does it.
I moved some tests from hmpp to `hmpp/multiplatformCompositeAnalysis`
because otherwise the tests would fail after I implement
`ExpectActualInTheSameModuleChecker` in the next commit.
Also the descriptor dumps were changed
(intermediateWithActualAndExpect.txt and
sealedInheritorsInComplexModuleStructure.txt). It happened because now
common source sets are no longer "squashed" into a single source set but
rather correct dependencies between source sets are established. And
each source set is analyzed separately (exactly like in
K2MetadataCompiler)
Ivan Kochurkin