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
This is not necessary and incorrect as it dependencies should not leak
to IDE import through this way. So reverting it back to original state.
But for KotlinNativeCompileArgumentsTest update context in the same way
as in Kotlin2JsCompileArgumentsTest and KotlinCompileArgumentsTest
just because KotlinNative Compilation classpath contain stdlib.
^KT-61430 Verification Pending
^KT-61559 Verification Pending
As part of KT-61559 stdlib is intended to be passed explicitly from
Gradle. However, CacheBuilder was not aware of such configuration
and was failing during cache building.
Author of this commit is Igor Chevdar
^KT-61430 Verification Pending
^KT-61559 Verification Pending
... platform dependencies while filter out them from actual compiler
invocation. So kotlin native compiler will provide them implicitly
from kotlin native bundle. Since K/Native compiler is not yet
optimised to consume platform dependencies explicitly and simply slow.
More details in related issue: KT-61559
^KT-61430 Verification Pending
^KT-61559 Verification Pending
The code is extracted from SetupKotlinNativePlatformDependenciesAndStdlib
as the latter is applied only to native compilations and
shared native metadata compilations.
For test shared native source sets, such as `nativeTest
no native metadata compilation is created, but for legacy import
intransitive metadata dependencies should contain native platform
dependencies listed. And
SetupKotlinNativePlatformDependenciesForLegacyImport fixes that.
^KT-61559 Verification Pending
They are now also exposed via KotlinCompilation.compileDependencyFiles
Which is useful for tools like dokka that relies on exhaustive
list of dependencies for given source set/compilation.
^KT-61559 Verification Pending
...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 MR fixes two independent issues causing build failures when using Kapt in combination with the Kotlin serialization plugin (and, very likely, with other plugins as well):
Kapt applied compiler plugins twice, causing errors similar to the one described in KT-65006
Kapt failed to generate @Metadata annotations for plugin-generated companion objects because the corresponding SLC missed containingFile needed for generation of method and class signatures
Merge-request: KT-MR-13970
Merged-by: Pavel Mikhailovskii <Pavel.Mikhailovskii@jetbrains.com>
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
Artem Kobzar