This allows us to properly complete array literals arguments of
annotation calls fixing several false-negative type mismatch errors
as well as enabling the inference of generic type arguments.
#KT-59581 Fixed
#KT-58883 Fixed
and assert that symbol is not a substitution/intersection override
in the `compute` method otherwise.
Because `fakeOverrideSubstitution` should be calculated for all real
implicit types, no call to this method should actually happen.
Otherwise, it can be problematic to create a session
which would contain the full designation path:
`provider.getFirCallableContainerFile(symbol)`
returns `firFile` of a super class which might be from module `a`,
when declaration and its outer classes are from module `b`.
^KTIJ-24105
^ KTIJ-24385
Temp property to store receiver is generated for `a.b++` expression.
If this property's psi corresponds to receiver expr, then FirProperty
would be found by mapper if receiver is requested.
It works unexpectedly, because FirProperty is normally not expected by expression.
This change set fake sources for generated FirProperty, so it won't be found
by source psi
^ KTIJ-24373
when resolving selector expr of a dot qualified expression,
parent qualified expression is resolved
see `KtFirCallResolver.getContainingDotQualifiedExpressionForSelectorExpression`,
Fir is filled with the data. Then,
during final mapping from Fir -> psi, one need to perform the opposite:
take `selectionExpression` to get the initial KtCallExpression
- If too few or too many type arguments were provided, they were all
thrown away in `TypeArgumentMapping`,
`FirCallCompletionResultsWriterTransformer`, and `KtFirCallResolver`.
The fix handles type arguments of the wrong arity more gracefully.
- Note for `TypeArgumentMapping`: Excess type arguments are not needed
for candidate resolution. Excess type arguments are still resolved
due to the handling in `FirCallCompletionResultsWriterTransformer`.
- Post-processing in `AllCandidatesResolver`: When all candidates are
resolved in `AllCandidatesResolver.getAllCandidates`, the function
builds a FIR file. During that resolution, the
`generic<String, String>` call (in example
`functionCallWithTooFewTypeArguments.kt`) is correctly marked as
inapplicable, but the missing type argument is inferred as an error
type. `firFile` then contains a function call
`generic<String, String, ERROR>` instead of `generic<String, String>`.
This call is still marked as inapplicable. Despite that, the
*subsequent* resolution by
`bodyResolveComponents.callResolve.collectAllCandidates` disregards
the call's inapplicability and resolves successfully into an
applicable candidate. This is because `CandidateFactory` doesn't make
any guarantees for already inapplicable calls. The fix adds
post-processing to `AllCandidatesResolver` to preserve candidate
inapplicability.
- Most tests that this commit changes had slightly different results due
to type arguments becoming resolvable.
- `wrongNumberOfTypeArguments.kt` and
`wrongNumberOfArgumentsInTypeAliasConstructor.kt`:
`ConeDiagnostic.toFirDiagnostics` prefers specific errors. Because
`ARGUMENT_TYPE_MISMATCH` is specific and `INAPPLICABLE_CANDIDATE` is
not, only the former is reported. I see no reason to pass an illegally
typed argument in either test, so the change reduces the errors to
`INAPPLICABLE_CANDIDATE`.
- `typeAliasSamAdapterConstructors2.fir.kt`: See KT-55007.
- Disable `mismatchTypeParameters` JS backend test due to its handling
of excess type arguments. See KT-55250.
^KT-54980 fixed
In K1 analogue of `K2_VISIBILITY_ERROR` is `K1_RUNTIME_ERROR`, so
candidates with `K2_VISIBILITY_ERROR` should win over innaplicable
candidates with `INAPPLICABLE`, `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
or `INAPPLICABLE_WRONG_RECEIVER` applicability
This is needed to allow resolution to invisible symbols (and later
suppress error with `@Suppress("INVISIBLE_SYMBOL", "INVISIBLE_REFERENCE")`
^KT-55026 Fixed
^KT-55234
- The Java functions aren't recognized as candidates during the test
(`FULL_JDK` isn't helping), so I've replicated the tests with local
extension functions and confirmed that they uncover the same
exception.
- `toResolvedCallableSymbol`: cast defensively because
the resolved symbol might not be a callable symbol.
- `toKtCallInfo`: Check that the resolved symbol is actually callable.
^KTIJ-23003 fixed
Make smart-casts non-transparent expression without delegation
to underlying FirQualifiedAccessExpression, as children delegation in
fir tree has unclear semantics
Remove two different kinds of tree nodes for smart-casts
Maybe in the future we could remove type from the
KtImplicitReceiverValue, because it has ktSymbol, and in theory
that should be enough to create corresponding KtType.
Unfortunately that is not the case for KtClassOrObjectSymbol --
it doesn't have the API for "default" type creation currently.
Regarding code in KtFirCallResolver.kt -- it seems like code there
needs some love in the future. Psi created via custom code there,
because for call x() FIR has receiver x with psi = null
aleksandrina-streltsova