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.
Only final builds (without build number) should be placed to Central.
Don't run the test for these builds while they are not published there.
Merge-request: KT-MR-8491
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
* Make CustomFinalizerProcessor mirror the existing FinalizerProcessor
* Fix Heap::PrepareForGC in custom allocator
Merge-request: KOTLIN-MR-616
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
Shouldn't affect the result, since in member functions all properties
are assumed to be initialized so the CFG is not needed for reporting
VAL_REASSIGNMENT.
Kirill Rakhman