A new resolution diagnostic UnsuccessfulCallableReferenceAtom is
introduced that is used in EagerResolveOfCallableReferences.
No diagnostic is reported on unresolved calls with this diagnostic
because
#KT-59856
Why did the problem existed?
At first, lambdas were analyzed with suspend function expected type,
because it's the WHEN-case and we propagate expected type info to
the branches.
Then, after the lambdas was introduced to the containing inference
system, we're creating ResolvedLambdaAtom using the information
from analyzed lambda's shape, but didn't use known lambda resulting
type (from which we might infer FunctionTypeKind).
So, the fix is just using that already obtained information.
^KT-57446 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
It's important to have ambiguity in these cases to introduce overload
resolution by suspend-modifier without breaking changes in future
Relates to #KT-23610
- Allow participating subtypes of functional types in conversions
- Fix several subtle inconsistencies
- Place logic about conversions at one place
Now conversions operations have two stages: before usual subtyping
check and after one. This is needed to support conversions of
subtypes (of functional types, for example). First, the compiler
checks if it possible to resolve an argument without conversion and
only then it tries to perform conversion.
Note that it'd be incorrect to perform conversion eagerly as it can
change resolve (Runnable & () -> Unit <: KRunnable), plus we can't
guess whether conversion is needed at all as it's important not to
look into supertypes if resolution doesn't actually needed it
#KT-36448 Fixed
#KT-37574 Fixed
#KT-38604 Fixed
Kirill Rakhman