See callingOuterGenericClassConstructorWithSelfTypes.kt
Previously, for A<B>(""), we used substituted constructor
where `X` was substituted with `B` (or `A<X>.B`).
But when resolving the call for constructor, we use `X`
as a type variable of the call, thus in some positions
we used `X` as TV (Xv in the comments) and somewhere `X` as a type
parameter, thus leading to contradictions (see clarifying comment).
The idea of the fix is simply repeating of the regular (not delegated)
constructor call resolution:
- We substitute only type parameters of outer class
- All the declared parameters of the callee are being checked
through regular resolution & inference mechanisms.
NB: Diagnostic only being reported on arguments because there
when we add `String <: Any` constraint it fails due to existing
contradiction in the CS.
Without the argument/parameter the error is just being lost, but that's
a different story (seeKT-65224).
^KT-64841 Fixed
Although these dumps don't really show if
something is a `FirFunctionCall` or a
`FirImplicitInvokeCall`, they do show what
goes into the receiver, and what are value
arguments.
In more details, we use either platform override checker (if we came
from platform) or the combined intersection scope override checker
at this place. Also this commit fixes various places around
JavaOverrideChecker, allowing to apply it in intersection override
checker properly:
- don't consider return types in this place
- apply JavaOverrideChecker if at least one candidate is from Java
- compare type primitivity closer to K1 logic
#KT-62554 Fixed
Partially fixes KT-63242
The primary constructor of a class needs to be the first subgraph of the
class control-flow graph. Based on the Kotlin specification, class
initialization order goes first primary constructor, in-place
declarations (properties and init blocks), and then secondary
constructors. If the class doesn't have a primary constructor, then it
is just skipped in the order.
Unfortunately, the class control-flow graph had in-place declarations
first and then all constructors. Instead, we should treat the primary
constructor as the first in-place declaration, and then continue with
the existing processing as secondary constructors. This will guarantee
that super constructor calls have the correct property initialization
information.
^KT-65093 Fixed
When using a field as the delegate for a super-interface of an object,
make sure uninitialized fields are not allowed. Specifically, disallow
access to these fields when referenced via object qualifier.
^KT-56489 Fixed
- Fix a false positive JS_NAME_CLASH report on constructors
from different classes but with the same JsName.
- Allow the same JsName for class constructors and other top-level
declarations. This behavior differs from K1, but it is correct
since there is no real name clash in the generated JS code.
^KT-64867 Fixed
Sort dependency modules topologically if they belong to the same KMP
project, preserving their relative positions. Sorting all modules and
changing positions of unrelated modules can be harmful: in the case of
a classpath hell, IDE results can become different from runtime
behavior. Sorting in place can help to avoid this problem, because
conflicting declarations shouldn't be allowed in different source sets
of the same multiplatform project.
KTIJ-27569
So, if a new component is registered in the compiler, it's not forgotten for the LL FIR
This registers `FirDelegatedMembersFilter` for K/N modules and fixes KT-64528
^KT-64528 fixed
We are using `ConeKotlinType` instead of `FirTypeRef` to represent
that element type of vararg doesn't have any source. It has a type
that was inferred. If we try to specify a source, then we could
end up with the incorrect place for diagnostic.
#KT-59682 Fixed
This fixes a compiler crash
IllegalStateException: Captured type for incorporation shouldn't escape
from incorporation
The crash occurs when a captured type with status FOR_INCORPORATION
is two layers deep inside a captured type with status FROM_EXPRESSION.
We first check if approximation is required for the most outer captured
type in AbstractTypeApproximator.approximateCapturedType.
Then we encounter the second captured type with status FROM_EXPRESSION
in AbstractTypeApproximator.approximateParametrizedType.
At this point, we stop checking and miss the third captured type with
status FOR_INCORPORATION.
Unfortunately, we can't check recursively if nested captured types
need to be approximated because of types with recursive super types
(the original reason why the extra check was introduced).
That's why we restrict the second check to types with recursive
super types, effectively restoring the previous behavior for all other
types.
#KT-65050 Fixed
The error-level enhancement is kept as warning-level and a new
LanguageFeature is introduced to turn the warning into an error.
#KT-63208 Fixed
#KT-63209
(cherry picked from commit 371b1eb3d5)
^KT-59074 Fixed
This solution is not ideal. Ideally, the allopen compiler plugin
shouldn't report `private` properites as `open` KT-64980, but it will
unpredictably break other things.
This fixes some type argument mismatch errors caused by a captured type
being approximated and then captured again.
Some places need to be adapted to work with captured types that
previously only worked with approximated types.
#KT-62959 Fixed
The inter-module interaction was partially supported, but the
DiagnosticCompilerTestFE10TestdataTestGenerated and
LFirPreresolvedReversedDiagnosticCompilerFE10TestDataTestGenerated were
failing. This is because the arguments of annotations were not fully
resolved in loadExperimentalitiesFromAnnotationTo function.
^KT-60262 Fixed
Denis.Zharkov