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 change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
It's necessary because even for stable a.b.c.d we can't guarantee that
this reference will always point to the same symbol because
different capture type instantiations generate different scopes
with different resulting symbol instances.
This is mostly a revert of 2f61a2f56f
There, we erroneously assumed that we may take captured types as equal
if they are based on the same-typed projections.
Each instance of capturing defines its own captured type,
that should not be equal to any other type captured in other place.
Initial motivation was brought by FP Ultimate, where a piece of code
from the new test was found that started working differently after
recent changes.
The most obvious consequence is the change in addAllProjection.fir.kt:
one cannot use an instance as an argument when expected type
is captured type based on the same instance.
Otherwise, it would lead to CCE if we allowed to put arbitrary charsequences
to the list that initially was a MutableList<String>
All other test data changes (but addAllProjection.fir.kt and differentCapturedTypes.kt)
are irrelevant and will be fixed in the subsequent commits
This directive anyway does not make test run twice with OI, and with NI
It only once run the test with specific settings (// LANGUAGE)
and ignores irrelevant (OI or NI tags)
To do so, inside the root cause of inapplicable candidate errors,
we will record expected/actual type of receiver, if any.
That will help identifying inapplicable calls on nullable receiver.
Hack: callee expression for when with subject variable is the subject
variable declaration. This solves the problem that all sub-calls in the
expression are implicitly considered to have a single common lexical
scope (and 'when (val x = ...)' introduces a new lexical scope, which
contains 'x').
'Subject.Error' is redundant.
'Subject.None' can be an object.
'Subject#dataFlowValue' can be a lateinit property.
TODO: fix
- parsing local extension properties in 'when' subject
- parsing destructuring declarations in 'when' subject
- non-completed calls in nested 'when' with subject variable
- non-completed calls for subject variable in 'in' pattern
Brian Norman