If a potential receiver is resolved to an error type, we consider
any other type as a subtype of it and therefore may select
any candidate that we happen to find in a scope.
In particular, in the case of scripts, or code with a context receiver,
the receiver candidate resolved to a cycle was accepted as a receiver
to an invoke on a random class from stdlib.
The fix skips adding invoke resolve task in this case, allowing
the tower to find the correct candidate in another scope.
#KT-64241 fixed
#KT-65576 fixed
There is a thing that `CandidateCollector` adds error candidate to the
list of resulting candidates only if its applicability at least the
same as current applicability of the collector
Also there is a problem, that deserialized symbol provider in CLI compiler
and stub-based symbol provider in AA may return the same declarations
in different order. This provokes the difference in the resulting set
of candidates between the two modes:
```
val x by unresolved
```
During the resolution of this code compiler tries to find function `getValue`,
and there are 6 of them in the stdlib. From them we are interseted in
specific three:
1. `fun <K, V> Map<K, V>.getValue(key: R|K|): R|V|`
2. `inline operator fun <V, V1 : V> Map<in String, @Exact V>.getValue(thisRef: Any?, property: KProperty<*>): V1`
3. `inline operator fun <V, V1 : V> MutableMap<in String, out @Exact V>.getValue(thisRef: Any?, property: KProperty<*>): V1`
- (1) is inapplicable with `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
- (2) and (3) are inapplicable with `INAPPLICABLE_WRONG_RECEIVER`
- `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR` is more specific applicability than `INAPPLICABLE_WRONG_RECEIVER`
- CLI compiler always sees those functions in order 1 -> 2 -> 3
- AA providers sometimes returns them in order 2 -> 3 -> 1
So in CLI compilation candidates (2) and (3) are not added to the resulting
set, as they are "less applicable" than (1), but in AA compilation they
can be added to the set before (1), which causes sporadic change in
FIR dump of `unsafeAssignmentExtra.kt`
To workaround this problem it was decided to treat `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
and `INAPPLICABLE_WRONG_RECEIVER` applicabilities as "equally specific"
^KT-65218 Fixed
Resolve it like a receiver of a call.
This makes the resolution result consistent with the equivalent
function call.
The K1 difference is covered by KT-66453.
#KT-66504 Fixed
This lets us get rid of some fallback code in FIR2IR that handles
unresolved argument lists.
After this, we should have an invariant that all non-empty argument
lists are resolved when FIR2IR runs.
#KT-66124
They are mostly necessary for argument mapping during resolution.
To support a couple checkers, we transform named args for varargs
into "fake" spread expressions.
Other than that, named arguments aren't needed for anything and often
lead to bugs where we forget to unwrap them for something, so it's
better to get rid of them.
#KT-66124
It's not really necessary if the information about if the lambda was a
trailing lambda can be directly saved in FirAnonymousFunctionExpression.
Removing the FIR node uncovered a couple of bugs
(UNINITIALIZED_ENUM_ENTRY, ERROR_IN_CONTRACT_DESCRIPTION) that were
caused by assuming that a lambda is always a trailing lambda.
#KT-66124
Instead, it should happen during BODY_RESOLVE phase.
This fixes KT-66150. The problem was, that `super<B>.f()` expression
in delegated constructor call was transformed during TYPES phase,
and type transformer has no special logic for allowing bare types in
super qualifiers, like the one in expressions transformer (see
`org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirExpressionsResolveTransformer.transformSuperReceiver`).
As a result, `B` without type argument leads to
WrongNumberOfTypeArgumentsError.
It looks incorrect that expressions in constructor call resolved
during TYPES phase, so skipping transformation of
argument list seems like the best solution here.
^KT-66150 Fixed
- encapsulate semantic more into helpers
- allow lazy scopes iteration
- simplify reporting code in tower resolver
- fix some inconsistencies and wrong lookups
- remove redundant lookup recordings
- remove lookup scopes for non-star imports
The commit is a refactoring and doesn't change the behaviour of
neither IC nor CRI. Changes in the lookups are mostly due to the
previous obviously wrong lookups (see changed test data).
This commit changes the behavior of KT-59138 effectively declining it in 2.0.
However, we plan to implement KT-59138 behavior under a feature
flag in 2.0 (see KT-66447), and switch this feature on version 2.x.
Also, this commit implements the LC resolution about postponing
KT-57014 change. We don't have KT-57014 described behavior in 2.0 anymore.
However, we plan to implement a deprecation warning here, see KT-65578.
After this commit, 6 diagnostic tests become incorrectly broken:
- 5 tests from PurelyImplementedCollection group
- a test platformTypes/nullableTypeArgument.kt
This commit also breaks currently fixed-in-k2 KT-50134
(it is fixed again in the following commits),
as well as KT-58933 (it will remain not fixed till we enable KT-59138
behavior again).
#KT-65596 In Progress
#KT-57014 In Progress
#KT-58933 Submitted
`recordAssignments` merges properties into all parents which is
redundant work in the case of empty `VariableAssignments`.
This redundant work leads to critically poor performance in cases
with many local declarations.
^KT-66416 Fixed
FirCallResolver tries to find a
candidate for the delegate's getValue and cannot parse an arrayLiteral
with a nullable coneType.Running
FirCallCompletionResultsWriterTransformer.transformArrayLiteral is
required to find the result type. Therefore, completeCall should not be
invoked with the ResolutionMode from the 'data' param, but rather in
ResolutionMode.ContextIndependent.
#KT-65022 Fixed
Previously, it was failing at line
(resolvedReceiver?.toReference(session) as? FirNamedReferenceWithCandidate)?.candidate?.updateSourcesOfReceivers()
But this line was mostly incorrect because in case of `a.b()` call,
which is resolved to `a.b.invoke()`, `resolvedReceiver` is pointing to
`a` instead of obviously expected `a.b`.
The fix with using `candidate.callInfo.explicitReceiver` doesn't help
either because the candidate of that receiver is always completed at
that stage (so no Candidate there).
The only case when the candidate was still there is PCLA because
in that case we explicitly don't fully complete even receiver
expressions.
(see docs/fir/pcla.md)
The idea of the fix is moving the call of `updateSourcesOfReceivers`
for invoke property receiver to the place just before the candidate
is being converted to the resolved reference
(i.e., the candidate is being lost)
^KT-66148 Fixed
During this phase, the compiler will evaluate initializers of
const properties and defaults of annotation's constructor.
Evaluation results will be stored in corresponding attributes.
#KT-64151
This fixes some cases where we infer some type variable inside one
of the branches to Nothing instead of the expected type because Nothing
appeared in some other branch.
Specifically, we add an equality instead of a subtype constraint during
completion of calls to synthetic functions for if/when, try and !!.
We don't do it when the call contains a (possibly nested) elvis or is
inside the RHS of an assignment.
Otherwise, we would prevent some smart-casts.
#KT-65882 Fixed
This extension point allows changing the return type of call
from a declared type to its subtype.
With an idea that such a plugin needs the ability to
control available (extension) properties for this type.
A set of properties should be decided based on the resolved function,
provided arguments, types, and resolved lambdas.
It is not a goal to enable plugins to affect resolution in any way.
Types are not intended to have any structured capabilities
In other words.
The goal was to come up with a way to enable a limited form
of an "extensible records" mechanism through plugins.
- It should give enough value for a practical use.
(more info in the ticket).
- It should have minimal effect on the compilation process
This appears to be an extension point that solves this problem.
^KT-65859 Fixed
This element has been introduced to simplify resolution logic in LL FIR,
but now this element is redundant and only complicates the code as after
KT-56683 `FirFile` has real phases
^KT-65876 Fixed
Instead of always looking up smart casts on `lastNode` and separately
tracking the receiver state, simply track which flow the smart casts
belong to right now. This tracked flow is auto-advanced when new
`lastNode`s are created, but can be manually rolled back for things like
KT-63709.
If there is an expression receiver, we should process constructors only
of inner classes. Constructors of nested classes can be called only
on classifier
^KT-65333 Fixed
... 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
This commit adds code to check whether a deserialized cone type is a
special function type kind or not when resolving the type of a lambda
expression (anonymous function). If it is a special function kind, it
sets the type of lambda based on the special function kind.
^KT-64994 Fixed
namely, add them to importing scopes directly and according to the
schema used for other implicit imports, rather than adding them
to the regular script file imports. See KT-65982 for explanation.
#KT-65982 fixed
Ilya Chernikov