For a class literal Type::class we are resolving Type as a constructor,
getting all diagnostics (about missing arguments, for example) and then
just not committing this trace with errors
#KT-37626 Fixed
This way the check works for callable reference arguments.
Also candidate applicability during resolution does not change compared to the old inference.
^KT-37530 Fixed
Move ParseUtils to 'psi', and ImportPath to 'frontend.common'.
Now 'psi' depends on 'frontend.common', and that allows to remove
dependency of 'fir:tree:tree-generator' on 'psi', allowing the former to
compile in parallel with the old frontend code.
Also move version string regex there and rename the class to
RequireKotlinConstants. This allows to get rid of dependency of
'serialization' on 'frontend'.
Add and handle the friend paths and refines paths compiler arguments;
Reuse klib dependency module descriptors in the resolver for project;
Issue #KT-37264
The new inference uses inferred intersection types normally, unlike the old inference.
However, intersection types in public declarations are approximated to supertype, which
potentially may give a less presice type, then it would be with the OI.
For non-related T1, T2 the NI approximates {T1 & T2} to Any in public declarations,
and if the OI was inferring T1 instead of the intersection type, it may lead to
less precise declaration type and related errors.
The solution is to remember an alternative for an intersection type when present.
Before approximation the alternative replaces the intersection type.
^KT-36249 Fixed
It's not clear how one should rollback _all_ resolution results if
there is inapplicable call. Ideally, such calls should not be available
in coroutine block but for now, to have backward compatibility, we'll
just reanalyze coroutine block as a usual lambda if there is at least
one such call.
As a result, also remove diagnostic about non-applicable call as it
become useless with current reanalysis
#KT-37061 Fixed
#KT-32097 Fixed
#KT-32203 Fixed
#KT-35306 Fixed
#KT-36202 Fixed
#KT-36220 Fixed
#KT-32654 Fixed
Originally reportFromPlugin method was introduced to address the problem
with loading of DefaultErrorMessages.Extension vis ServiceLoader.
For some cases this extension was not loaded by ServiceLoader because
classes was loaded via different class loader, common scenario here is
compiler plugins. Ideally we should load such extension point via
getService approach, but unfortunately to do that we need project and
DefaultErrorMessages.render is static method for now.
Also with reportFromPlugin approach is a problem -- all diagnostics
reported via this method has the same id: PLUGIN_[WARNING|ERROR|INFO]
and it isn't possible to suppress only one particular diagnostic.
To bypass this problem the new method
initializeFactoryNamesAndDefaultErrorMessages was introduced.
It basically store DiagnosticRenderer inside DiagnosticFactory.
It is not ideal, because one DiagnosticFactory could have different
renderers for different scenarios -- for compiler and for IDE, but
I think that it is better than reportByPlugin approach.
In this test `kotlin` was resolved to the extension
`val Class<T>.kotlin` because it was saved in builder-inference.
Usually, it's fine, but not for qualified expressions as they have
fallback resolve in case of error
rapturemain