It's hard to achieve that without implementing part of `externRefToAny` using an intrinsic. It should be rewritten when all VMs and tools update to the latest spec.
Also, stop using (deprecated) instructions unsupported by SpiderMonkey.
#KT-56166 In-Progress
Previous implementation set Nth ModuleDescriptor dependencies to the
first N modules. This is not always correct: for example, when producing
a metadata klib (-Xmetadata-klib) for HMPP, metadata dependencies might
have inexact or missing depends= in their manifests.
This commit sets ModuleDescriptor dependencies to all other
deserialized modules. The same approach is used for K1. That way, the
implementation is more reliable.
^KT-56071
Old implementation expected that builtIns should be based on a library
with no dependencies, usually stdlib. But that doesn't work properly in
some cases, e.g. when producing a metadata klib (-Xmetadata-klib) for
HMPP. In that case, some of the metadata dependencies can have no
depends= in the manifest, leading to the compiler choosing such a module
instead of stdlib.
This commit makes it look for a library that is explicitly stdlib
instead.
^KT-56071
There were still some cases where the generated function reference class
would contain references to generic parameters that were not in scope.
One example of that was `Array<*>::get`. Before this fix the generated
function reference class would still contain a reference to the
type parameter declared in the `Array` class.
Also, the logic of generifying the generated function reference class
was incorrect. For example, for function `fun <A, B> foo()` if we had
a reference `::foo<T, T>` (where `T` comes from the outer scope),
the class would still contain two generic parameter, despite that only
one generic parameter from the outer scope was referenced.
This is also fixed here.
The existing threshold for determining between medium and large page
does not take the dummy block into account, meaning that an allocation
on the threshold will lead to a loop that only terminates when the
process goes out of memory.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-618
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
IJ-203 dependency has illegal reflective access usage, which is prohibited without a special flag since JDK17. Specific reflect usage was fixed on the IntelliJ side (IDEA-31024). After the new IC was present in 1.8.0, this problem shows up on modules with a large number of source files in Maven projects. During the incremental compilation, FileSnapshotMap is filled up with paths to files as keys, so in the test, we generate a lot of source files with long names. If there are a lot of files to compile, a key chunk with paths overflowed and drops the current chunk to the disk, after that PersistentHashMap caches FilterOutputStream and uses illegal reflective access.
Closing caches after the first IC attempt fix this problem:
`63a0660c` IC: Close caches before falling back to non-incremental compile
`908dbf32` IC: Clean up closing caches logic in IncrementalCompilerRunner.kt
authored by Hung Nguyen
This commit should be reverted after the update of IJ dependency (KT-47765)
#KT-55709 Fixed
Merge-request: KT-MR-8359
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Conditions for being isolated do not hold anymore:
it tested that addSuppressed extension could work without kotlin-stdlib-jdk7,
but now the latter is merged to kotlin-stdlib and thus always present
#KT-51907
Also introduce -Xsave-llvm-ir-directory argument
that should be used instead of -Xtemporary-files-dir
as a location for LLVM IR from phases.
Motivation for this change: it is simpler to implement
and unties LLVM actions from the awful TempFiles class.
Zalim Bashorov