A progress indicator is important for calling old Java-based API which falls into WSL+Ijent. Without the progress indicator, the function may freeze for unpredictable time.
GitOrigin-RevId: 04a063c555391ee12295882b9a713082aa38fefa
To ensure that we can change how runtime module descriptors are generated without requiring everybody to update their IDEs, the implementation from module 'intellij.devkit.runtimeModuleRepository.jps' is attached to the build process as a library 'devkit.runtime.module.repository.jps'.
GitOrigin-RevId: 11fb0d872aa5ac8981f026f2bf3077bcebd52af6
This behavior was broken when BuildManager migrated to listen for events from Workspace Model instead of using rootsChanged. ChangeSourceFileSetTest didn't catch that because BaseCompilerTestCase still used rootsChanged.
GitOrigin-RevId: c5d67bfb423faa723b7b6c355fe07bd01906bd16
Before it was done inside postStartupActivity, and skipped in tests. The new way may slightly improve performance (the listener won't be loaded until something is actually changed in the workspace model), helps to avoid race conditions (what if project configuration is changed before startup activity finishes?). Also, since the listeners now work in tests as well, we'll be able to get rid of custom logic in tests, and they may start catching bugs like IDEA-344089.
GitOrigin-RevId: 74489f5ea1121fae04aa51920f265ac6fe29e8f7
This makes BuildManager class a little shorter, and will look better when the listener is registered separately in plugin.xml.
GitOrigin-RevId: 48740b49850813f884ad4a94755c17ec3f5b6a98
It'll help us to avoid guessing when we need to use the global or project `VirtualFileUrlManager`
GitOrigin-RevId: 93a8a62634d3b3b284b85c3ca1187403fefc90cc
A common anti-pattern is to check that some file exists before doing any operation with the file. The approach is wrong with two reasons:
* The check for the file existence implies at least one additional system call. System calls are expensive in general and are absurdly expensive for WSL file system.
* The file still may be deleted by an external process after the existence check but before the handling. So, such approach sometimes simply doesn't work as expected.
`java.nio.file.Files.exists` is especially slow on Windows, because it tries to create the file under the hood. See `sun.nio.fs.WindowsFileSystemProvider.checkReadAccess`.
This commit removes the unnecessary `Files.exist`. Instead, the code invokes the intended system calls directly, but the code is ready to catch and handle `FileNotFoundException`.
On my machine, the change helped to reduce the total time of execution of `com.intellij.compiler.server.WslBuildCommandLineBuilder#copyPathToTargetIfRequired` from 129 seconds to 3 seconds.
GitOrigin-RevId: d7093e28c6230bcc3c315b00acaf53f6ee20f28f
To get a version of the storage, `currentSnapshot` should be used.
`WorkspaceModelImpl` and `VersionedEntityStorage` are marked as internal. `WorspaceModelImpl` should has an internal modifier, but this is currently not possible because Rider overrides it. `VersionedEntityStorage` may be removed in future at all.
There are some cases when the version of the storage is accessed. Probably we can create a special function to return an entity storage with its version.
This is a part of IJPL-345
GitOrigin-RevId: cc3d6c47099c91c54d571d7ca13c5ef9d84265a9
Such objects are also types, so there is no need to specify a type every time the external index is accessed.
GitOrigin-RevId: eba99e669c4d7fe9dcb8bf1a2908d518e1ed4aea
