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
Call argument for conventional `contains` after expanding `in` may come from a `when` subject during its branch analysis.
In this case data flow info from a previous when branch was not considered,
because data flow info for subject had been used instead of data flow before argument.
Use of the latter one for the conventional `contains` solves the issue.
The old FE uses `isExternal` property of value arguments to skip smartcast reporting on `when` subject,
if they come from branches. To prevent undesired smartcasts on `when` subject after branch analysis in the new FE,
`isExternal` arguments are skipped in diagnostic reporter and during recorded type update.
Also, the new FE interprets `isExternal` completely differently from the old FE.
In the old FE this property is used exclusively by `when` with subject.
In the new FE it is also used for parially resolved calls, lambda return arguments and receivers.
This may be preventing the use of data flow info before argument in the first place, but this assumption requires additional investigation.
^KT-36818 Fixed
While we have an overload resolution algorithm working for O(n^2),
call resolution for the single particular call may work more then just
a second.
Thus, we need to call ProgressManager.checkCanceled() with more granularity
^KT-35135 Fixed
New resolution applicability is needed in cases when error is found,
but candidate still should be selected. Currently there are two cases,
when this behaviour is required:
- unstable smartcast (choose candidate with non-nullable parameter)
- unknown lambda parameter type (against non-functional expected type)
KT-36264
There are several issues with unsafe desugaring for convention calls.
Proper fix is not implemented here (see design proposal KT-30872).
This commit only applies the old logic in the new inference.
^KT-30695 Fixed
Type parameters can't be specified explicitly for special constructions.
Reporting this error does not help fixing the cause of it and needlessly
reveals implementation details.
^KT-36342 Fixed
Reported diagnostics from the call checkers didn't get to a top-level
trace, if an intermediate wrapping call was a lambda call.
Use of the top-level trace in call completer is a workaround for
the unreliable commit order of common calls' temporary traces.
^KT-33542 Fixed
From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
Callable reference is "adapted" if it requires some adaptation to an
expected function type - e.g., when a reference to
```
fun foo(vararg xs: Int): Int
```
is used where `(Int, Int, Int) -> Int` is expected.
For such callable references we generate the following IR (in
pseudo-Kotlin):
```
{
fun foo'(p0: Int, p1: Int, p2: Int): Int {
return [| foo(p0, p1, p2) |]
}
::foo'
}
```
where `[| foo(p0, p1, p2) |]` is calling function `foo` with arguments
`p0`, `p1`, and `p2`, as they were mapped by callable reference
resolution.
Sergey Igushkin