`@JsFun("code")` is now executed inside a JS function which brings its
`arguments` into the scope shadowing D8's CLI `arguments`.
Accessing arguments through `globalThis` fixes the problem.
Merge-request: KT-MR-8630
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
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
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
Calling '.addAll()' was replacing convention value leading for inability
to add/modify Kotlin/Native link task freeCompilerArgs via
KotlinCompilation.options.freeCompilerArgs. For now convention
was replaced by normal value.
^KT-56280 Fixed
depends on closure of its default source set.
With HMPP it is no longer needed, since each source compiles
independently and sees its parent declarations via klib dependencies
^KT-55730 Verification Pending
The check itself happens during application time, remove the health
check wrapper for reporting to make the code more clear. One downside is
that the warning could be reported on misconfigured projects, but it's
a minor inconvenience.
KT-55891
MPP plugin applied to a root project leads to false positive reports
in its subprojects. Also, granular metadata flag is not supposed to be
set in subprojects. Reporting only for the root project should cover
most of the cases.
KT-55891
* Replace it with KotlinCompilerVersion
* K/N version should be set now with `deployVersion`.
* Cleanup deprecated functions in older versions
of the Gradle plugin
* Cleanup tests for older versions of compiler downloader
Merge-request: KT-MR-8436
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
Some patches could add new file and after hard reset they are not
deleted. This leads to patch apply failure.
Updated JGit otherwise clean command was not working properly.
Martin Bonnin