This has no effect on behavior, but will fix a binary compatibility
problem with Compose.
#KT-54459 Fixed
Co-authored-by: Alexander Likhachev <Alexander.Likhachev@jetbrains.com>
A non-trivial intersection override should be created if:
1. the base methods are from different classes (for proper reporting of
diagnostics if an override is necessary);
2. OR the return type might need to be intersected (which currently
happens for non-subtyping scopes if there is no single maximally
specific declaration)
Currently, compiler pipelines are heavily couples with
NamedCompilerPhase. Unfortunately, NamedCompilerPhase uses the same
type for Input and Output, thus it is not applicable to phases that
try to transform some data purely.
Thus, we separate this class into two, allowing to have a new
inheritor of NamedCompilerPhase with different Input and Output types.
CommonBackendContext is a complex interface that
actually requires many things to be instantiated.
We don't need it for many parts of compilation pipeline:
frontend or object files phases in native backend would
work just fine without CommonBackendContext.
PhaseConfig is tied to some root `compoundPhase` that
defines the whole compilation pipeline. To lift this restriction
and allow dynamically-defined compilation pipelines, let's move
parts of PhaseConfig interface that do not depend on `compoundPhase`
to an interface.
- Remove unused params from compilerWithIC wrapper.
- Move JsIrBackendContext creation logic into separate function
- Introduce and use compiler interface for IC infrastructure
On dirty rebuild we may reload IR from stdlib,
such reloading may affect files with intrinsics and builtins.
As soon as we load only exported symbols, we must track dependencies
for files with intrinsics or builtins as for others.
This patch implements the logic which updates dependencies for
the stdlib files after loading of intrinsics and builtins.
^KT-54323 Fixed
See KT-49404 for details
In K1, within SubstitutingScope we approximate almost all the types
containing captured types are being approximated to either a lower or
an upper bound.
While mostly, it's being done correctly there are some problems with
approximations for flexible types
So, the parameter's type of A<in Any>::foo is approximated to Inv<in Any!>,
thus allowing to use Inv<*>, while it's obviously unsound.
NB: For the similar example, in B, there are regular TYPE_MISMATCH
because parameter for B<in Any>::foo is approximated to Nothing
Also, it's important to say that
- in K2 everything works because we don't use type approximation there
- approximation algorithm that works incorrectly is only being used in K1
^KT-54332 Fixed
Alexander Udalov