For now, without retries.
First pass collects all test classes without executing them.
Then they run either one by one, or grouped by package.
GitOrigin-RevId: cbdea0a64313cdc1dd0bbc6a281b9cd679c2a512
First from here: com.intellij.util.indexing.FileBasedIndexPluginListener#beforePluginUnload
And also from here: com.intellij.util.indexing.FileBasedIndexImpl#FileBasedIndexImpl
Keep only one (the most generic) place - FileBasedIndexPluginListener. Unregistering ID on plugin unloading is not correct in general case, because it clear index.id-plugin association, but will keep index storages. Old storages may accidentally be accessed by another plugin declaring an unrelated index extension with the same index.id (name collision).
(cherry picked from commit 38cbc7d0a809194f32327535fbb6657f63ec2834)
GitOrigin-RevId: 2b40c44635948b0f2b36b148f428b2e29f8dc331
The freeze was caused by a big number of modules with compiler plugins.
For each of them, we inspected the jar corresponding to the compiler plugin,
and that is an IO operation that takes time.
Since we use a multithreaded resolve, it was possible for multiple
threads to come and try to initialize the cache in `KtCompilerPluginsProviderIdeImpl`,
but only one of them could actually make progress because of `SynchronizedClearableLazy`.
The fix has three parts:
Firstly, it turns out that, in most cases, all the modules
are actually referring to the same compiler plugin jars.
So, instead of doing N jar inspections to create the
classloader for the compiler plugins' registrars,
it's better to compute the unique jars first,
and only then do the jar inspection.
Secondly, we use a faster implementation of reading a file from
the compiler plugin jar. In my local benchmark, it is approximately
50-60% faster than the previous implementation.
Thirdly, we add `checkCanceled` check before calling IO-intensive
`findCorrespondingBundledPlugin`, so that even if this freeze happens
again, at least it is possible to cancel the thread which occupies
the lock in the `SynchronizedClearableLazy`
With those changes combined, this should bring the chances of
such a freeze in a real project to a minimum
GitOrigin-RevId: 0b6865da24204a4de26d4a081462b999221d033a
`stopProcess` checks whether the future is finished before scheduling a new task to avoid many re-schedules.
However, in this case, the future will never be in finished state, because `stopProcess` is called from the inside of it.
So, the analyzer will never schedule a new task here.
To allow the future to finish before `stopProcess` is called, we can postpone its execution by using `invokeLater`. By the time `stopProcess` is executed, this future is going to finish, so the check can succeed.
Fixes rare issue in RDCT-933 when analyzer doesn't finish editor analysing.
GitOrigin-RevId: 5ecb914ce2b3c792988853955fcb9a03d6fc9129
The change was done for getFrameProxy, getThread, getLocation methods. Before they relay on the technical thread from the JVM suspend event. Now they will refer to the active stack (selected in the frames view). It should fix a lot of bugs about incorrect evaluation, stepping and so on.
IJ-CR-129700
GitOrigin-RevId: 2fab3728d7dba0b92b1b055c9d7cdace1e5ddea1
This additional method should fix the performance degradation.
This method can be removed after the review IJPL-862
GitOrigin-RevId: 3e12b3b0cdf719732675b5ce0007f29850e87fcb
Julia Beliaeva
Andrey Lisin
Kirill.Karnaukhov
Nikita Barkov
Vladislav Rassokhin
Andrei.Kuznetsov
Mikhail Kuznetsov
Petr
Roman Golyshev
Sergey Pak
Daniil Ovchinnikov
Kate Botsman
Alexey Merkulov
aleksandrina-streltsova
Aleksey Pivovarov
Mikhail Mazurkevich
Arkady.Bazhanov
Alex Plate
Ekaterina Berezhko
Roman Shevchenko
Vladimir Krivosheev