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.
In the new dynamic driver we have various contexts, inputs and outputs.
To make it possible to validate and dump IR uniformly, we need a couple
of adapter interfaces that will be accessed from phase actions.
It contains only commented CheckSamSuperTypes phase which is disabled
for quite some time. If we ever need this lowering again it could be
found in this commit.
Svyatoslav Scherbina