For example in the case:
<_A extends @NotNull B, B> void f4(_A x, B y) { }
ISE had happened because while substituting the function
we've been creating copies of old type parameters and when initializing
bounds for one of them bounds for other may not be initialized yet
at the same time bounds were necessary for makesSenseToBeDefinitelyNotNull
Use type refiner to correctly expand actual type alias - expect
class chains, produced by the commonizer. In a case when type
refiner doesn't exist for module create a one-shot thread local
instance. This might happen with modules without source code
in project (coming from build system model).
^KT-46691 Fixed
ExpectedActualResolver in certain cases needs an ability
to create a standalone refiner instance, see the following
commits. A direct module dependency (resolution -> frontend)
can't be added, the opposite one already exists which leads
to a dependency cycle. Both modules depend on core.descriptors
module where KotlinTypeRefiner resides.
KT-46691
There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.
Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
Previsously, errors have been ignored because we ignored errors raised
from the completion phase
See the comment above the createConstraintPartForLowerBoundAndFlexibleTypeVariable
Remove any logic related to finding the single parameter of the primary
constructor, and use inlineClassRepresentaton from IrClass or
ClassDescriptor instead.
This will be used at least in the JVM backend instead of the current
approach where we're loading the primary constructor's first parameter,
which isn't good enough since primary constructor can be private, and
we can't rely on private declarations in case they're declared in
another module.
In FE10-binding I would like to re-use equal and hashCode mechanics
that was implemented in AbstractTypeConstructor, but I don't need
the supertype implementation, because it already there in FIR
Dmitriy Novozhilov