Before:
- The cinterop task's output files were added as file dependency
to the declaring target's apiElementsConfiguration
- A 'copy' task was created for the cinterop artifact that was added
to the apiElements configuration as artifact (and therefore also
to the apiElements-published). This copy task placed the
same klib into the 'libs' folder
- Before passing libraries to the compiler the, all files
that are likely to be the result of the 'copy' task (in any libs dir) were
filtered
After:
- The cinterop task's output files are *not* added as file dependency
- The cinterop task's output is added as artifact directly to
the 'apiElements' configuration
- There is no more need for a copy task
- There is no more need for manually filtering the 'libs' artifacts
Tested:
project to project dependencies,
project to project dependencies (with KGP based dependency resolution)
project to repository
project to repository (with KGP based dependency resolution)
^KT-37051 Verification Pending
This commit fixes:
```
./gradlew :kotlin-native:backend.native:compileCompilerKotlin -PdeployVersion=1.9.0-dev-900
```
`-PdeployVersion=1.9.0-dev-900` is important for reproducibility (it's
not necessarily `1.9.0-dev-900` any version starting with `1.9.0-dev`
will reproduce the problem)
FunctionalTypeKind can be used in FE 1.0 too, so there is no need to
keep both classes. Also, removal of FunctionClassKind simplifies work
with FunctionalTypeKind in common code, like Analysis Api
This is needed because now set of available synthetic functional interfaces
depends on session, because each module can contain different plugins,
which provide different kinds of functional types
This is needed to provide an ability to extend different kinds of
functional types
Also, cleanup and rename utilities related to functional types to avoid
possible confusions
Being disabled by default
and not well-documented, these functions cause confusion among early
adopters as to why their code don't work properly.
Assert APIs need a proper design across Kotlin platforms.
Since APIs are not available in common code and K/JS, it is premature
to have such a general feature in a new experimental platform.
Compiler tests:
* Mute tests that rely on assert.
* Replace JVM-specific assert calls with require calls and unmute passed K/JS tests.
Merge-request: KT-MR-8636
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
- `FirTypeResolverImpl.resolveSymbol` cannot simply assert that a type
parameter only has a single qualifier, because code may be fed to the
compiler where a type parameter is the start of a type chain (see for
example the added `typeParameterChainInReturnType` test).
- The fix assumes that any multi-qualifier type parameter trivially
resolves to `null`, because such a chained type cannot exist.
^KT-56212 fixed
^KTIJ-24083 fixed
During import, cinterop generation is lenient (as there
might be good reasons why certain hosts can't generate some
cinterop klibs). In this case, the resolution for IDE
should be lenient too. When a cinterop file is resolved, that is
not present on disk, we just send a 'IdeaKotlinUnresolvedBinaryDependency'
instead.
KT-56337
When constraint system has forks in it usually we solve all of them before
starting full completion of corresponding call. But if some call with
forks was a last statement of postponed lambda, we will never call
completion for it with FULL mode. Instead of it we complete it in PARTIAL
mode and then just merge its constraint storage into storage of outer
call. So all forks from this inner call just remain unresolved inside
outer system without this fix
^KT-55966 Fixed
^KT-55808 Fixed
Review: https://jetbrains.team/p/kt/reviews/8401
If I don't bump `versions.kotlin-native` then locally
`kotlinx.coroutines` & `kotlinx.atomicfu` user projects compilation
fails with message:
```
w: skipping /home/bobko/jb/kotlinx-atomicfu/atomicfu/build/classes/kotlin/metadata/commonMain. Incompatible abi version. The current default is '1.7.0', found '1.8.0'. The library produced by 1.8.255 compiler
e: Could not find "/home/bobko/jb/kotlinx-atomicfu/atomicfu/build/classes/kotlin/metadata/commonMain" in [/home/bobko/jb/kotlinx-atomicfu, /home/bobko/.konan/klib, /home/bobko/.konan/kotlin-native-prebuilt-linux-x86_64-1.8.20-dev-5812/klib/common, /home/bobko/.konan/kotlin-native-prebuilt-linux-x86_64-1.8.20-dev-5812/klib/platform/linux_x64]
```
It worth noticing that we hardcoded "1.9.0-dev-693" on CI
(kotlin-teamcity-build/6693cb229c7485e07241fbc28322344774bcc3e0) to
workaround KTI-1107. 1.9.0-dev-693 also bumps KotlinAbiVersion
Review: https://jetbrains.team/p/kt/reviews/8401
- Drop unused variables
- Replace `assert` with `require` because `assert` isn't reliable which
makes hard to do any judgements about the code (`-ea` flag must be
passed to the VM for the `assert` to be active. And it's hard to know
when we the flag is passed). If `assert` was here for the performance
reasons then a comment should have been left.
- Add the assert message for clearity
Because I'm evaluating what will break if KotlinAbiVersion is bumped.
And when the code around KotlinAbiVersion is clean it's easier to do the
evaluation.
Review: https://jetbrains.team/p/kt/reviews/8401
In scope of: KT-55082
Because this version isn't used for anything. We have KotlinAbiVersion
to version the IR format.
Review: https://jetbrains.team/p/kt/reviews/8401
- Code style
- Drop unused properties in kotlin-native/build.gradle
- kotlin-native/build.gradle: drop unused import
- use final instead of open when possible
This is just a cleanup commit. It neither fixes any issue/bug, nor
introduces new behaviour.
Feel free to revert this commit if you find out that it breaks something
Review: https://jetbrains.team/p/kt/reviews/8401
BinaryVersion is a problematic class, because it doesn't represent any
logical entity in the codebase, it's just a way to reuse common logic
for Kotlin versions. But unfortunately, BinaryVersion is used in a lot
of API definitions, which makes code hard to read because it's not
obvious which subclasses are supposed to be passed in the particular
API.