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)
Previously, containingDeclarationSymbol for V was set to the outer class
BaseRoot, so its upper bounds was computed to the ones from TNested
at org.jetbrains.kotlin.fir.resolve.calls.CreateFreshTypeVariableSubstitutorStageKt.getTypeParameterFromExpandedClass
^KT-56706 Fixed
See the relevant test at t/
estData/codegen/box/sam/contravariantIntersectionType.kt
After the previous commit, when generating a call for `doOnSuccess {}`,
we have a SAM type with removed projection Consumer<Any?>, while
real function type of the lambda is a bit different
(Function1<ConcreteType & ConcreteType2>).
While for me, that looks questionable, but in K1 it was effectively
resolved via the same implicit cast that on JVM is generated to an
INVOKEDYNAMIC that wraps initial function-typed value.
^KT-53552 Fixed
It would be more consistently to prohibit the behavior from the unmuted
test (see KT-52428), but it was decided to postpone the breaking change.
Unfortunately, it didn't work to make a test where for computing
star projections we would need to substitute other type parameters
because effectively, it's not allowed to have SAM conversion when
star projections/wildcard is based on a type parameter which bounds
use other type parameters.
^KT-53552 In progress
These declarations should not be visible to users (and therefore are not added to FIR),
but plugin itself can reference them in already compiled serializable classes,
and therefore they should be available in metadata:
- synthetic deserialization constructor
- static write$Self function
See also:
^KT-55885
- KT-56505 occurred because `source.getChild(KtNodeTypes.MODIFIER_LIST)`
returns any modifier list in the subtree of the source element, not
necessarily the modifier list belonging to the checked element.
`depth = 1` restricts the search to the modifier list belonging to the
checked element itself.
- For example, given `f1` from KT-56505, `getChild` would return the
modifier list of `public var foo = 0`. Because it contains a
visibility modifier, `f1` wasn't marked with
`NO_EXPLICIT_VISIBILITY_IN_API_MODE`.
^KT-56505 fixed
- In explicit API mode, the `public` visibility modifier is not
redundant unless a declaration is hidden by a container. The
`REDUNDANT_VISIBILITY_MODIFIER` diagnostic is now not reported in such
cases.
^KTIJ-24485 fixed
- `REDUNDANT_MODIFIER_FOR_TARGET` is already reported for `open`
interfaces, but for consistency and IDE support, the compiler now
reports `REDUNDANT_MODALITY_MODIFIER` as well via the extended
checker.
- `REDUNDANT_MODIFIER_FOR_TARGET` cannot be disabled for this case
because it's reported via a basic checker while
`REDUNDANT_MODALITY_MODIFIER` is reported via an extended checker.
- Rename `implicitModality` to `redundantModalities` and return a set of
modalities. The idea of a *single* implicit/redundant modality doesn't
stand up to scrutiny. For example, for interfaces with `ABSTRACT`
implicit modality, `OPEN` is also a redundant modifier. But this is
not necessarily the case for all kinds of declarations.
Hypothetically, if it was possible to declare a class that is abstract
by default, adding an `open` modifier to that class would not be
redundant, as it would make the class instantiable.
Construct compiler plugins classpath based on original
compiler arguments
Support of plugins in full pipeline test allows us to test projects
where some common compiler plugins are used without excluding modules
^KT-56075
Alexander Udalov