`FirDeserializedEnumAccessExpression` requires session to build proper
reference, so it's important to have it in all utilities, which may
pass this element as input
^KT-64975
When there is a return statement within a lambda, and the return
statement contains a lambda, data-flow information from the inner lambda
is not being passed correctly to the surrounding lambda. This is because
return statements which had a lambda target would drop all postponed
lambda exits, but should instead forward those exits to the surrounding
lambda exit.
^KT-59729 Fixed
^KT-64268 Fixed
See callingOuterGenericClassConstructorWithSelfTypes.kt
Previously, for A<B>(""), we used substituted constructor
where `X` was substituted with `B` (or `A<X>.B`).
But when resolving the call for constructor, we use `X`
as a type variable of the call, thus in some positions
we used `X` as TV (Xv in the comments) and somewhere `X` as a type
parameter, thus leading to contradictions (see clarifying comment).
The idea of the fix is simply repeating of the regular (not delegated)
constructor call resolution:
- We substitute only type parameters of outer class
- All the declared parameters of the callee are being checked
through regular resolution & inference mechanisms.
NB: Diagnostic only being reported on arguments because there
when we add `String <: Any` constraint it fails due to existing
contradiction in the CS.
Without the argument/parameter the error is just being lost, but that's
a different story (seeKT-65224).
^KT-64841 Fixed
The primary constructor of a class needs to be the first subgraph of the
class control-flow graph. Based on the Kotlin specification, class
initialization order goes first primary constructor, in-place
declarations (properties and init blocks), and then secondary
constructors. If the class doesn't have a primary constructor, then it
is just skipped in the order.
Unfortunately, the class control-flow graph had in-place declarations
first and then all constructors. Instead, we should treat the primary
constructor as the first in-place declaration, and then continue with
the existing processing as secondary constructors. This will guarantee
that super constructor calls have the correct property initialization
information.
^KT-65093 Fixed
We are using `ConeKotlinType` instead of `FirTypeRef` to represent
that element type of vararg doesn't have any source. It has a type
that was inferred. If we try to specify a source, then we could
end up with the incorrect place for diagnostic.
#KT-59682 Fixed
This fixes some type argument mismatch errors caused by a captured type
being approximated and then captured again.
Some places need to be adapted to work with captured types that
previously only worked with approximated types.
#KT-62959 Fixed
Previously, error types on those implicit parameters were being lost.
Changed test data is only partly here
(only parts that are considered to be correct).
Other ones (new green-to-red changes) should belong to the next commit
and will be fixed soon (as a part of PCLA).
It's expected to partially mimic the behavior of what
previously was called builder inference, but with more clear contracts
(documentation is in progress, though)
See a lot of fixed issues in the later commits with test data,
especially [red-to-green]
^KT-59791 In Progress
Instead, use specific resolution mode handled by call completer.
Mostly, it's done for simplification of PCLA implementation because
otherwise we would need to track how PCLA inference session and the
one for augmented should be combined.
But just independently of this, not using inference session here,
it looks just simpler.
^KT-59791 In Progress
Initially, it was a bug caused by unfortunate copy-paste, but there were
no tests for this because mostly `delegation` operators are functions
But after PCLA is implemented, many tests start failing
For example, FirPsiOldFrontendDiagnosticsTestGenerated.Tests.BuilderInference.OneParameter.OneTypeVariable.OneTypeInfoOrigin.TypeInfoSinks.testImmutableProperties
^KT-59791 In Progress
Before this change `ARGUMENT_TYPE_MISMATCH` would complain that
`Y` "is not a subtype of" `Inv<Y>`, because the function would only
check immediate bounds of the type parameter `Y`. `chosenSupertype`
would be `X`, not `Inv<out kotlin/String>`.
^KT-60056
When performing lookahead for local variable assignments, make sure
assignments taking place within loops are being propagated before loops.
This makes sure smartcasts within non-inline declarations before the
loop are disallowed.
^KT-63867 Fixed
Previously, we would ignore the candidate with the non-smartcasted
receiver if they have the same symbol.
Now we prefer them when they're visible or when the smart cast changes
the nullability.
This is required for the following commit where candidates from the
original scope in presence of smart cast will not be ignored if they're
the same symbol.
Before this commit, we assumed (erroneously) that a captured type
cannot have an associated SAM-based function type.
In this commit we changed this assumption, replacing a captured type
with its lower type for this purpose
#KT-63379 Fixed
We should use the declaration-site session to have stable
resolution order. The same scheme is applicable during
regular lazy resolution calls.
Also, this means that we should process 'expect' classes
before 'actual' like it was for 'super' and 'sub' classes
^KT-63547
We cannot skip resolution in the case of type actualization as we cannot
guaranty that there are no any classes in super types which can be
actualized in the current context
^KT-62832 Fixed
^KT-63547
Before this commit, we discriminated particular candidates with callable
reference adaptations during resolution stages.
After disabling compatibility mode for new inference, it's not so,
but now we discriminate similar candidates in ConeOverloadConflictResolver;
more precisely, it's candidates with callable reference adaptation
in their postponed atoms.
This does not allow going up the tower,
but allows to select better candidate at similar tower level.
Related to KT-63558, KT-64307, KT-64308
Before this commit, we discriminated particular candidates with SAM
during resolution stages. More precisely, candidates from Kotlin
which used Java SAM types, were discriminated allowing go up the tower
for better candidates. After disabling compatibility mode for new
inference, it's not so, but now we discriminate similar candidates
in ConeOverloadConflictResolver. This does not allow going up the tower,
but allows to select better candidate at similar tower level.
Related to KT-63558, KT-64306
The problem from KT-63624 was that during matching phase we must choose
only one candidate, but in Java we can have two successfully matched
properties: 1) from field and 2) from method, which overrides Kotlin
property.
See test `propertyAgainstJavaPrivateFieldAndPublicMethod.kt`.
As a result, we choose field candidate, throw away method candidate, and
then fail during visibility check.
Instead of inventing special rule of prioritizing field over method
it was decided to prohibit actualization to Java field at all because:
1. It doesn't seem that Java fields actualization was implemented in K1
on purpose
2. People usually don't use public Java fields, and use instead
private field + getter, especially when compatibility is important, so
it shouldn't be a breaking change
Besides that, such solution simplifies code and is consistent with
the current logic of matcher, which doesn't expect that two members
can be matched successfully. Also, it fixes KT-63624 and KT-63667.
^KT-63624 Fixed
^KT-63667 Fixed
There are many complications with the current design of passing data
from within in-place lambdas to surrounding code. Solving these
complications will involve more time to investigation than is available
within the K2 release. So we are disabling passing type statement
information from lambdas for the time being until more time can be
devoted to a more complete solution.
^KT-60958 Fixed
^KT-63530 Fixed
This commit addresses a scenario where an 'actual' declaration is marked
with a Deprecated annotation at the 'Hidden' level, while the
corresponding 'expect' declaration is not. When resolving,
'CheckHiddenDeclaration' marks the 'actual' declaration as unsuccessful,
leading to the selection of the 'expect' declaration as the successful
candidate.
'FirDeprecationChecker' handles a case where an 'actual' class is
annotated with Deprecated, but the 'expect' class is not. During the
checking of the 'actual' class constructor, 'CheckHiddenDeclaration'
skips it due to the absence of a direct Deprecated annotation.
'FirDeprecationChecker' then identifies this constructor and reports a
DEPRECATION_ERROR.
'FirDeprecationChecker' will now be applied to solving problems related
to 'actual' declarations with corresponding Deprecated annotations. The
process remains the same: 'CheckHiddenDeclaration' will skip the
'actual' declaration, and then 'FirDeprecationChecker' will identify it
and report the error.
^KT-61792 Fixed
MT stands for "modularized tests"
^KT-64166 Fixed
Review: https://jetbrains.team/p/kt/reviews/13517/timeline
This commit fixes:
java.lang.IllegalArgumentException: Local <local>/<anonymous> should never be used to find its corresponding classifier
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirProviderImpl.getFirClassifierByFqName(FirProviderImpl.kt:252)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirProviderImpl$SymbolProvider.getClassLikeSymbolByClassId(FirProviderImpl.kt:60)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.computeClass(FirCachingCompositeSymbolProvider.kt:131)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.access$computeClass(FirCachingCompositeSymbolProvider.kt:27)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider$special$$inlined$createCache$1.invoke(FirCachesFactory.kt:75)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider$special$$inlined$createCache$1.invoke(FirCachesFactory.kt:69)
at org.jetbrains.kotlin.fir.caches.FirThreadUnsafeCache.getValue(FirThreadUnsafeCachesFactory.kt:40)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.getClassLikeSymbolByClassId(FirCachingCompositeSymbolProvider.kt:158)
at org.jetbrains.kotlin.fir.resolve.transformers.mpp.FirExpectActualResolver.findExpectForActual(FirExpectActualResolver.kt:41)
Dmitriy Novozhilov