- 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
Added checker for FirEqualityOperatorCall. It's surfaced as one of the
following diagnostics depending on the PSI structure and types under
comparison:
* INCOMPATIBLE_TYPES(_WARNING)
* EQUALITY_NOT_APPLICABLE(_WARNING)
* INCOMPATIBLE_ENUM_COMPARISON_ERROR
Comparing with FE1.0, the current implementation is more conservative
and only highlights error if the types are known to follow certain
contracts with `equals` method. Otherwise, the checker reports warnings
instead.
However, the current checker is more strict in the following situations:
1. it now rejects incompatible enum types like `Enum<E1>` and
`Enum<E2>`, which was previously accepted
2. it now rejects incompatible class types like `Class<String>` and
`Class<Int>`, which was previously accepted
3. the check now takes smart cast into consideration, so
`if (x is String) x == 3` is now rejected
If a type paramter is not reified or nullable, different errors will
be reported by FirGetClassCallChecker.
When determining whether type parameter wrapped in qualified access is a
standalone expression or not, we examine whether the checker context has
other qualified accesses in stack. Class literals (::class) is desugared
to FirGetClassCall, and thus not stacked as qualified access. Since
class literals are a special type of callable reference (a subtype of
qualified access), we should keep track of FirGetClassCall in a similar
way.
This commit introduces several different things, in particular:
- check type arguments in expressions
- new TypeArgumentList node to deal with diagnostic source
- ConeDiagnostic was moved to fir:cones
- ConeIntermediateDiagnostic to use in inference (?) without reporting
- detailed diagnostics on error type
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
Despite the fact that the LHS of a double colon expression is now KtExpression
instead of KtUserType, we must still consider it a type for callable references
to work. Extract and reuse relevant parts of QualifiedExpressionResolver and
TypeResolver to support this behavior
Infer something sensible instead of error types when an error is reported, such
as absence of a type argument for Array or presence of type arguments for other
types
Marco Pennekamp