As the result of the latest changes to stdlib, the muted test succeeds.
Thus "java.lang.AssertionError: Test contains MUTE_LL_FIR directive but
no errors was reported. Please remove directive".
It was decided to unmute the test for now until the compiler team
fixes the issue. See KT-65218
Previously, error types on those implicit parameters were being lost.
Changed test data is only partly here
(only parts that are considered to be correct).
Other ones (new green-to-red changes) should belong to the next commit
and will be fixed soon (as a part of PCLA).
Before, we were wrapping the original constraint position into
ConeBuilderInferenceSubstitutionConstraintPosition twice during the
constraint substitution in builder inference.
It was causing problems with diagnostic reporting.
Remove TODOs about diagnostic reporting from FirBuilderInferenceSession.
Propagation of errors from the common system is now implemented
Diagnostic reporting in updateCalls isn't needed, since we
report errors after the system completion unlike K1
Relates to KT-53749
Pass constraint errors from the integration system into a candidate to
make sure it is reported later.
Related to KT-59426, KT-59437, KT-53749
#KT-55168 Submitted
This uses the same approach as
INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION where we use a visitor
to find a call to a symbol that contains the type variable in question.
#KT-56140 Fixed
Previously, updateTypeInBuilderInference was calling
updateTypeFromSmartcast to actually perform type update in
implicit receiver after stub types was inferred
Such action results in creation of following FIR:
FirSmartCastExpression(
original=FQAE(FirImplicitThisReference, typeRef=R|Inv<Stub>|)
typeRef=R|Inv<String>|
)
in receiver position during completion of calls
However, it wasn't the case in general situation due to
action of FirStubTypeTransformer, which, in turn visits and updates
type ref inside original expression, but only if there was at
least one call (that was completed) using that implicit receiver
As after such type update updateTypeFromSmartcast function does
nothing
Yet in situation, when there was only partially resolved calls
referencing that implicit receiver we actually create smart-cast
expression and don't update type
The change just removes usage of updateTypeFromSmartcast and
replaces is with direct type update
We still mutate state of implicit receiver, potentially
improperly, it should be addressed in future
^KT-54708
^KT-58365 Fixed
For explanation, see nestedPartiallyResolvedCallsSimple.k
The problem was caused by "select" variable is being leaked to the
inference session of delegate while it should not happen because
it doesn't belong to the common system of `KotlinVal { ..` call,
as we complete it with fixing `E` variable during completion
for `A(select(null, fun(): Int { return 1 }))`.
The root of the problem is that we were adding all the partial
nested calls to the session, while in fact we only need there
the top-level one.
^KT-57543 Fixed
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
Note: in this test, we create a flexible type from two captured types
during substitution, which provokes exception from
FlexibleTypeImpl.runAssertions() (they are run only in test mode)
Related to KT-54198
* 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
In this commit we upgrade FIR builder inference logic from
the compiler version to 1.7. FIR-based compiler now works with
"don't use builder inference" flag always ON and supports switching
the flag "use builder inference only if needed". To do it,
ContraintSystemCompleter (FIR) and KotlinConstraintSystemCompleter (FE 1.0)
are made similar with extracting some common parts into
ConstraintSystemCompletionContext.
Test status: one BB test fails after this commit (KT-49285).
Also we have a crush in DFA logic in FIR bootstrap test and somehow
questionable behavior in FIR diagnostic test. However,
two BB tests were fixed, the 3rd case from KT-49925 were also fixed.
#KT-49925 Fixed
Abduqodiri Qurbonzoda