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
When expected type is known, use it as expected type for branch bodies.
While it indeed becomes different from the usual select call resolution,
where expected type is applied only after completion starts,
it helps to support, e.g. callable references resolution just as powerful
as it was in K1.
Also, in some cases where diagnostics have been changed, they become
a bit more helpful since they are reported closer
to the problematic places
cannotCastToFunction.kt test has been removed because it relied
on the case erroneously supported by the hack removed from
the FirCallResolver in this commit.
^KT-45989 Fixed
^KT-55936 Fixed
^KT-56445 Fixed
^KT-54709 Related
^KT-55931 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
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
Elvis now is being resolved a bit differently and in case
of inconsistent types, the while expression has error type,
but no diagnostic is reported since the element has no valid source element
When one sets the source
https://github.com/JetBrains/kotlin/commit/817316cdc93457c1de7cf10c3b422e3a4b486e5b
it brings back the issue KT-45989 that was effectively unresolved but hidden
due to diagnostic loss
^KT-45989 Open
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Changes from FE1.0:
1. As discussed previously, no expression evaluation happens during this
check.
2. FE1.0 doesn't check redundant object comparisons.
FIR simply ignores anything after the first comma if the when expression
doesn't have a subject. Hence, the checker has to rely on PSI structure
instead.
FE1.0 only reports SENSELESS_COMPARISON if one of the operand is `null`.
This change makes FIR reports also in case one of the operand has type
`Nothing?`.
In addition, fix handling of type alias in ConeTypeContext#isNullableType
In order to make resolution still work for members not available from
`Nothing`, we track the type without `Nothing?` and use that for
resolution instead.
These two diagnostics are similar: both are reported on type references
to enum entries. But `IS_ENUM_TYPE` is reported if the type ref is an
operand of `is` operator. To pass along this contextual information, a
boolean is added to FirSpecificTypeResolverTransformer.
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)
Dmitriy Novozhilov