- 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
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
It's necessary because even for stable a.b.c.d we can't guarantee that
this reference will always point to the same symbol because
different capture type instantiations generate different scopes
with different resulting symbol instances.
The job is already done at CheckExtensionReceiver resolution stage
And repeating it might only lead to incorrect errors caused by
double-capture of receiver type that leads to contradiction because
in previous commit we started assuming different capture instantiations
as different types.
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
Some of the changed tests may duplicate other existing diagnostics,
but that should not be reason not to report them at all.
There might be another job to be done to avoid diagnostic duplications
For example, NEW_INFERENCE_NO_INFORMATION_FOR_PARAMETER
It became especially relevant after 0e84bf2053
that together with later commits bring a lot of unnecessary
NEW_INFERENCE_NO_INFORMATION_FOR_PARAMETER diagnostic
This flag is true by default but is set to false for
- Java methods and constructors
- interface delegation methods that delegate to Java
The NAMED_ARGUMENTS_NOT_ALLOWED logic is mostly refactored to use the
new flag though some custom logic remains for determining the correct
message and to work around a corner case with fake overrides.
The flag is (de)serialized from/to metadata. For backward compatibility
with K1, delegated methods to Java types are deserialized as stable.
^KT-40480 Fixed
- Also, this error allows IDE to provide quick-fix that changes language
version in a project that simplifies the adoption
- There is no point in
changing K2 part as there this feature will be enabled by default
^KT-56224 Fixed
- `FirTypeResolverImpl.resolveSymbol` cannot simply assert that a type
parameter only has a single qualifier, because code may be fed to the
compiler where a type parameter is the start of a type chain (see for
example the added `typeParameterChainInReturnType` test).
- The fix assumes that any multi-qualifier type parameter trivially
resolves to `null`, because such a chained type cannot exist.
^KT-56212 fixed
^KTIJ-24083 fixed
When constraint system has forks in it usually we solve all of them before
starting full completion of corresponding call. But if some call with
forks was a last statement of postponed lambda, we will never call
completion for it with FULL mode. Instead of it we complete it in PARTIAL
mode and then just merge its constraint storage into storage of outer
call. So all forks from this inner call just remain unresolved inside
outer system without this fix
^KT-55966 Fixed
- In contrast to other kinds of dependencies, `dependsOn` dependencies
must be followed transitively.
- Add `transitiveDependsOnDependencies` to `KtModule`. These
dependencies are calculated lazily with a topological sort. They are
added to the dependency provider when it's built in
`LLFirSessionFactory`.
^KT-55329 fixed
- `IncDecOperatorsInExpectClass.kt` should produce an
`ACTUAL_WITHOUT_EXPECT` in K2 (see KT-55177). This went unnoticed
because of KT-55570.
- A similar multi-module test for K1 and K2 has been added, called:
`multiplatform/incDecOperatorsInExpectClass.kt`.
- FirExpectActualMatcherTransformer: Instead of returning,
`transformMemberDeclaration` must assign an empty map to
`expectForActualData` so that `FirExpectActualDeclarationChecker`
doesn't assume that the member declaration needs no expect-actual
checking.
^KT-55570 fixed
Nikolay Lunyak