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.
One of the previous commits moved calculation of diagnostics from
FirAnalyzerFacadeinto the separate test service, so it should be altered
in AA tests too
There are two ways of test service registration:
- manual call to `useAdditionalServices` in abstract test runner
- using of `additionalServices` property in one of test entity (e.g. in handler)
Services are registered in the same order (manual first, automatic second)
This led to the situation that if there was registered more specific
implementation of the service in the test configuration, it will be
overridden with regular implementation from handler, which is fixed
by this commit
There are some cases when we want to run some platform checker not from
platform session but from common session. All such cases appear when
we check some `expect` class
```kotlin
// MODULE: common
expect interface A
expect class B : A
class C : A
// MODULE: platform()()(common)
actual interface A {
fun foo()
}
actual class B : A {
override fun foo() {}
}
```
In this example we want to report "abstract foo not implemented" on
class `C`, but we don't want to report it on `expect class B` (as
its supertype is always `expect A`, never `actual A`)
So to cover such cases some platform checkers were split into two parts:
- `Regular`, which is platform checkers and runs for everything except
expect declaration
- `ForExpectClass`, which is common checkers and runs only for expect
declarations
^KT-58881 Fixed
^KT-58881 Fixed
^KT-64187 Fixed
This commit introduces MppChecker kind, which represents the new property
of checkers
- `MppCheckerKind.Common` means that this checker should run from the same
session to which corresponding declaration belongs
- `MppCheckerKind.Platform` means that in case of MPP compilation this
checker should run with session of leaf platform module for sources
of all modules
An example of a platform checker is a checker that checks class scopes
and reports ABSTRACT_NOT_IMPLEMENTED and similar diagnostics. If some
regular class in the common module contains expect supertypes, the
checker should consider the actualization of those supertypes to get
a complete type scope
^KT-58881
In the following commits, there will be a need to retrieve the scope of
the same class from different sessions, so we need to consider the
session as part of the key along with class symbol
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
...by honoring accessors' visibility
We need a special handling for backing field visibility,
e.g., lateinit, const, or JvmField, but that's not the case
for accessors' visibility.
^KT-64937 fixed
- Shared application environments can be disposed in the middle of test
plan execution when the project count reaches zero. So resetting
`ApplicationManager` only on "test plan execution finished" is
incorrect, because it does not account for that scenario. Instead, we
should reset `ApplicationManager` every time the application
environment is disposed.
- We should also keep the manual reset in `testPlanExecutionFinished`
because `disposeApplicationEnvironment` may not need to dispose
anything if there isn't a shared application environment, but we
should still reset `ApplicationManager` if an unshared application
environment was created.
- This fixes "Some test disposed, but forgot to clear MockApplication"
exceptions which appeared after KT-64099 because it opened up proper
disposal of the shared application environment (instead of it being in
a state of leakage because not all project disposables were properly
disposed).
^KT-63650
^KT-64099
This is the last test in the Klib and was run separately.
Instead, it should be located with 'kotlin-util-io' project which it tests
Merge-request: KT-MR-13978
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
- 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
In K2 we have `EXPLICIT_TYPE_ARGUMENTS_IN_PROPERTY_ACCESS`
and `EXPRESSION_OF_NULLABLE_TYPE_IN_CLASS_LITERAL_LHS`
which seem to cover the same use cases as
`RESERVED_SYNTAX_IN_CALLABLE_REFERENCE_LHS` used to
(at least it seems so, based on the source code of
`resolveReservedExpressionSyntaxOnDoubleColonLHS()`).
^KT-59835 Obsolete
This is more convenient behaviour for debugging with klib-tool than
just failing.
Note that enabling Partial Linkage globally in klib-tool is undesirable,
as it can auto-tweak IR (e.g. when overrides do not match), thus
distorting the rendered IR
^KT-61143 Fixed
Denis.Zharkov