According to logs, ProjectFileBasedIndexStartupActivity.onProjectClosing is invoked via message bus. Probably, it is invoked after myOpenProjects.add(project), but before fileBasedIndex.registerProjectFileSets(project). Try moving myOpenProjects.add(project) to the very end. In message bus event has already passed, the filter should be removed via disposable registered on project dispose.
GitOrigin-RevId: 2ebe4ea429d7f150ee13a48bc66af83f872e9f11
We will fix global lock on Windows soon, such a longer splash is less actual nowadays. The proper implementation is not easy.
GitOrigin-RevId: 0bf9f6004c87f1d94680b1cac64294a59d190e79
The inline modifier allows using these functions in both threading models (blocking and suspendable)
GitOrigin-RevId: 14bd358a291cdadcee5da9b042813f58302080de
To find and report native crashes `PerformanceWatcherImpl` requires two files: `.pid` and `.appinfo`
These files are stored in the system directory (`PathManager.getSystemPath()`).
For JetBrainsClient we replace default system path (`JetBrains/IntelliJIdea[VERSION]`) with custom per process path (`JetBrains/JetBrainsClient[VERSION]/tmp/per_process_system_0`)
This custom directory is cleaned up on every start therefore `.pid` and `.appinfo` files are also deleted and `PerformanceWatcherImpl` cannot send crash reports.
To fix that, we now keep these files between client restarts.
GitOrigin-RevId: 7c50445d07767cc3a12e36c5511778235e8142b6
Problem: The initial issues KTIJ-27480 [AE "Can't find built-in class kotlin.Cloneable" on opening build.gradle.kts with broken syntax highlighting] and KTIJ-25236 ["AssertionError: Can't find built-in class kotlin.Cloneable" after reload build.gradle.kts configuration] arose due to the following chain of events: we attempt to resolve a KTS script ⇒ in the script dependencies, we found a symbol for which Kotlin built-ins need to be created ⇒ creating of built-ins depends on the SDK and stdlib ⇒ (1) we find the SDK from the module to which this library is bound ⇒ (2) in our case, buildSrc module has no source set, so the library ends up hanging and not bound to any module ⇒ sdk=null ⇒ built-ins=Default (instead of JVM ones) ⇒ the required built-in is not found ⇒ internal resolve error. Such a situation (2) can occur if, for example, the buildSrc module does not have source folders and the Kotlin plugin is not applied. In this case, its list of source roots will be empty, and all libraries needed to resolve the script are not bound to any modules. Important notice: here we determine the SDK from the module. This behavior appears only when using the Composite resolver (only in the case of MPP projects). In the case of SEPARATE mode - the SDK is provided for the entire project, and such an error does not occur, while in SEPARATE it is prohibited and the SDK needs to be computed depending on the module.
Motivation: The situation where a library is not associated with any module because it is only used in a script remains unhandled. In this fix, we take into account this possible scenario and handle it to ensure correctness.
Solution: at the moment of building the mapping (1) between libraries and modules that use them, we also use information from `ScriptConfigurationManager` (if the search by direct dependencies does not yield results), to find the script that depends on this library. From this script, we add SDK information.
Note: in general, the architectural problem lies in the lack of context - in resolving, we can come to the same library from different contexts - scripts have their classpath, which requires the use of the Gradle JDK, the same library can be in the dependencies of buildSrc - there user can set any JDK using the toolchain. We can also find this library through symbol search. Thus, it turns out that the same library can have different environments, about which nothing is known at the moment.
^KTIJ-27480 Fixed
Merge-request: IJ-MR-129468
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
GitOrigin-RevId: 151c0bc82278ad379a8c091bcfc46850c9d83e9e
+ adjust sampling params: sample less often, but make single sample heavier, collect more samples for reporting for more precision of high %-tiles
+ reduce reporting precision: double->float
GitOrigin-RevId: e42c422b6ca7d55019a44b220ae0d8633866f05f
Andrei.Kuznetsov
Vladimir Dolzhenko
Mikhail Pyltsin
Dmitriy.Panov
Georgii Ustinov
Vladimir Krivosheev
Sergei Vorobyov
Eugene Zhuravlev
Daniil Ovchinnikov
Anna Kozlova
Kate Botsman
Ilya.Kazakevich
Alexey Kudravtsev
Anna.Gromova
Aleksei.Cherepanov
Ruslan Cheremin
Julia Beliaeva
Louis Vignier
Vera Petrenkova
Bart van Helvert