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
during tail-call optimization.
There can be code, where all next instructions are non-meaningful and
there is a back-edge, for example, while(true){}. Previously, analyzer
incorrectly assumed, that this cannot happen. Now, it keeps track of
visited instructions and says, that there is no meaningful instruction
in such case.
#KT-56815 Fixed
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
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
- 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
If a synthetic prop clashes with a real property (e.g. @JvmField
property from parent Kotlin class), don't generate fake override for the
synthetic property. This fixes a CONFLICTING_INHERITED_JVM_DECLARATIONS
error in a mixed hierarchy.
^KT-56538 Fixed
It's been introduced in the previous commit
("K2: Simplify handling mixed smartcast vs. original candidates")
Because previously, it was assumed wrongly that each next level of
ConeCallConflictResolver filter out the candidates that are 100% less
applicable/specific, but the main one (ConeOverloadConflictResolver)
either leaves the single candidate or the whole same set, thus at
FilteringOutOriginalInPresenceOfSmartCastConeCallConflictResolver
we've got 4 candidates only two of which we might filter out.
The idea is that when we have successful candidates both from smart cast
and original type, we should discriminate in the favor of former ones.
While this problem (see kt55722.kt) existed before this branch is merged,
initially it was recognized on FP Ultimate when we stopped assuming
captured types from the same projections as equal (see kt55722Initial.kt).
^KT-55722 Fixed
^KT-55024 Fixed
^KT-56283 Related
^KT-56310 Related
This is mostly a revert of 2f61a2f56f
There, we erroneously assumed that we may take captured types as equal
if they are based on the same-typed projections.
Each instance of capturing defines its own captured type,
that should not be equal to any other type captured in other place.
Initial motivation was brought by FP Ultimate, where a piece of code
from the new test was found that started working differently after
recent changes.
The most obvious consequence is the change in addAllProjection.fir.kt:
one cannot use an instance as an argument when expected type
is captured type based on the same instance.
Otherwise, it would lead to CCE if we allowed to put arbitrary charsequences
to the list that initially was a MutableList<String>
All other test data changes (but addAllProjection.fir.kt and differentCapturedTypes.kt)
are irrelevant and will be fixed in the subsequent commits
Namely, do not choose `Nothing?` result type when fixing a variable
that has other constraints besides the ones that came from
the relevant type parameter's upper bounds.
See more details in KT-55691.
In K1, the case from specialCallWithMaterializeAndExpectedType.kt
was working (inferred to String?) just because the branches
were analyzed independently with `String?` expected type.
This change became necessary after the previous commit when we united
inference subsystems for if/when branches (see motivation there).
NB: For K1, the behavior is left the same, but the code
was refactored a bit.
^KT-55691 Fixed
^KT-56448 Fixed
Otherwise, it leads to branches inference run fully independent,
while there are cases when it's necessary to flow type information from
one of the branch to another (see the new test).
NB. In K1, it worked differently: if branches were inferred altogether
only for Any/Any? expect types (otherwise they're analyzed independently)
See foo2/foo4 in the test.
To avoid breaking change we need to support foo1/foo3, but we're trying
not to have some special rule for Any, so we've got a new resolution mode
that provides expect type, but doesn't require full completion.
^KT-45989 Fixed
^KT-56563 Fixed
^KT-54709 Related
For change in specialCallWithMaterializeAndExpectedType.kt
At first, see at KT-36776
Long time ago, it's been decided that if/when resolution
should look similar to similar "select()" calls,
but it's a breaking change (see KT-36776), and we were ready for that back then.
But then, there were too many broken cases found, thus we reverted it at
100a6f70ca
But probably, it would be better to try to infer `String?`
instead of `Nothing?` (see next commits)
Note that change in specialCallWithMaterializeAndExpectedType.kt
will be addressed in later commits, too
When expected type is known, use it as expected type for branch bodies.
While it indeed becomes different from the usual select call resolution,
where expected type is applied only after completion starts,
it helps to support, e.g. callable references resolution just as powerful
as it was in K1.
Also, in some cases where diagnostics have been changed, they become
a bit more helpful since they are reported closer
to the problematic places
cannotCastToFunction.kt test has been removed because it relied
on the case erroneously supported by the hack removed from
the FirCallResolver in this commit.
^KT-45989 Fixed
^KT-55936 Fixed
^KT-56445 Fixed
^KT-54709 Related
^KT-55931 Related
Beside some corner cases, it's already prohibited in K1 because
adaptation have a bit strange nature
(they don't represent any existing real function exactly)
^KT-55137 Fixed
Mikhail Glukhikh