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.
Do not report same set of diagnostics for variable call if actual
error was happened with a function candidate. Here the candidate is
invoke function on DeepRecursiveFunction
^KT-40991 Fixed
^KT-41491 Fixed
^KT-40926 In Progress
It might be necessary for cases like
run @l1{
run {
if (...) return@l1 1
}
}
"if" is a synthetic call, but without candidate since there's just one branch
But return@l1 1 is incomplete because it's resolved in dependent context
and "1" is hang incomplete integer literal
^KT-44055 Fixed
It's possible only if there is a callable reference among subcalls which go though the old type inference (and the error for uninferred type parameter wasn't reported)
It leads to leak such type to the back-end. Calls within a builder call should be updated without marking CR and lambdas with DONT_CARE type.
^KT-43845 Fixed
^KT-43956 Fixed
^KT-42622 Fixed
Update includes:
- Changing syntax of `OI/`NI` tags from `<!NI;TAG!>` to `<!TAG{NI}!>`
- Fix some incorrect directives
- Change order of diagnostics in some places
- Remove ignored diagnostics from FIR test data (previously `DIAGNOSTICS` didn't work)
- Update FIR dumps in some places and add `FIR_IDENTICAL` if needed
- Replace all JAVAC_SKIP with SKIP_JAVAC directive
Namely, remove incorporation “otherInsideMyConstraint” to eliminate
constraint system redundancy and produce a potentially very large number
of constructs.
Instead, introduce not so “spreadable” incorporation during variable
fixation (equality constraint with result type into other constraints).
^KT-41644 Fixed
^KT-42195 Fixed
^KT-42920 Fixed
^KT-42791 Fixed
^KT-41741 Fixed
Previously helpers from checkType.kt was in special package, and
if directive was enabled then test runner (`AbstractDiagnosticTest`)
injected additional imports to test files and removed them after test
was completed.
It's very hard to support such behavior in new test infrastructure so
there was a decision about changing `CHECK_TYPE`:
1. All helpers from `checkType.kt` now stays in default package
2. `CHECK_TYPE` only adds `checkType.kt` to set of analyzed files
and don't modify their content
For test which are written in default package (most of tests actually)
there are no changes. On the other hand if there is a test where dev
want to use checkType functions in testfile with some package then he
should explicitly import functions which he needed (`checkSubtype`,
`checkType`, `_`)
Several tests are affected by the usage of fixation direction calculator in FIR.
Restored to mimimize test data changes.
It is unnecessary in FE10 because a type variable with unknown type
is inferred into an error type, but affects test data in FIR where
Nothing/Any is selected by direction (as a temporary measure).
CR candidate in spec test is Unresolved in FIR because top-level CRs are resolved as call arguments.
Resolution ambiguity is also present in FE10 when CR is wrapped into an id call.
Repeat the logic of KotlinConstraintSystemCompleter in ConstraintSystemCompleter.
Implement additional context operations required for updated lambda completion algorithm.
Jinseong Jeon