... when the expected type is not a function type.
Instead set it to a new type variable.
This fixes a bunch of false negative CANNOT_INFER_PARAMETER_TYPE.
#KT-59882 Fixed
Although these dumps don't really show if
something is a `FirFunctionCall` or a
`FirImplicitInvokeCall`, they do show what
goes into the receiver, and what are value
arguments.
This commit does two things:
- prioritize type parameter scopes against static scopes in body resolve
(effectively it's a revert of KT-58028 fix)
- consider type parameters as inapplicable callable, so during callable
resolve we can go up the tower and still resolve to static scope
This allows both KT-58028 and KT-63377 to work properly
#KT-63377 Fixed
Checking the current applicability isn't enough because in the presence
of multiple diagnostics, the lowest applicability can be successful but
a higher one isn't.
#KT-63147 Fixed
K1 reports `ARGUMENT_TYPE_MISMATCH`
and `TOO_MANY_ARGUMENTS` together, and
one way to do it in K2 is to say that
their kinds of inapplicability difference
is not relevant to the user.
Note that K1 doesn't do such filtering,
so this change "makes K2 closer to K1",
but still different.
^KT-62541 Fixed
fixup! [FIR] Show ARGUMENTS_MAPPING_ERROR diagnostics along with INAPPLICABLE
NB: In general, it's unclear what to do in cases
like the following one, even when sometimes
we could, indeed, prefer something:
```
fun foo(a: Int, b: String, c: Boolean)
fun foo(b: String, c: Boolean, a: Int)
foo(c = false, b = "", a = 0)
```
^KT-55933 Fixed
- At first, get rid of a kind of interceptTowerGroup callback and use
explicit towerGroup construction instead
- Get rid of INVOKE_RECEIVER (not sure exactly why it was needed)
- Make comparison consistent with tower-levels priority of K2
(see the comments in the compareTo code)
^KT-37375 Fixed
^KT-58940 Open
When reporting INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION, search
for a call to a declaration with the type parameter that got inferred
into an empty intersection inside the expression.
#KT-56377 Fixed
When a call is resolved to a classifier, only a single error message was
being used for multiple cases. This lead to confusion as the default
message may not be applicable to a given error case. Added additional
errors and messages to distinguish between these error cases.
#KT-57251 Fixed
Previously, when a candidate was found with an applicability that is
better than the current best applicability, all previous candidates were
thrown away. Now we keep them, unless the new applicability is
successful. If no successful candidates are found, we fully resolve all
the unsuccessful ones and select the ones with the least bad
applicability. This improves diagnostics for unresolved calls.
#KT-57844 Fixed
Before this commit, for property candidates in K2 their types wasn't
inferred/susbtituted properly.
So, when candidate for fooBar.liveLoaded.invoke() was created,
the type of `fooBar.liveLoaded` was just X type parameter for which
there is no any `bar()` functions in its member scope.
While proposed semantics is a bit different from K1, where
both property and invoke candidates are united into common system,
it doesn't contradict to the specification (https://kotlinlang.org/spec/overload-resolution.html#callables-and-invoke-convention)
which says explicitly that invoke-convention should be desugared as
`r.foo.invoke()`, thus `r.foo` should be completed independently.
Also, this strategy supports some reasonable use-cases like KT-58259
while it's still a breaking change but for more artificial-looking
situations (see KT-58260) and should be passed through
the language committee.
The changes in stubTypeReceiverRestriction* tests looks consistent
because of how `genericLambda` now works
(with full completion of property call).
NB: The code is going to be red once KT-54667 is fixed and also there's
already similar diagnostic in K1 (INFERRED_INTO_DECLARED_UPPER_BOUNDS)
^KT-58142 Fixed
^KT-58259 Fixed
^KT-58260 Related
This fixes a false positive TYPE_PARAMETER_IS_NOT_AN_EXPRESSION when
a type parameter and some member, static or companion declaration have
the same name and referred to inside a class.
#KT-58028 Fixed
The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
The expression needs to be resolved first to determine if there is a
receiver that needs to be extracted to a temporary variable. Also, the
special case for prefix increment/decrement on local variable without
delegates requires resolution to check if the variable is local.
^KT-56771 Fixed
^KT-56659 Fixed
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
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
- 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
Kirill Rakhman