`BrowseFolderRunnable` and `*WithBrowseButton` family: getting rid of separate "title" and "description" parameters in favor of the chooser descriptor object, to avoid cloning the latter down the road.
GitOrigin-RevId: 33ec5968a1db953c60848974135055c288accf85
The quick fix copies the `@Deprecated` annotation from the overridden declaration to the overriding one.
^KTIJ-29564
GitOrigin-RevId: 1c079a2e6ef8729c428e7f19c378d73f5655543b
It does not make sense to replace a value in `entityCache`
if it was concurrently inserted by someone else.
GitOrigin-RevId: f28ff2357ced479942bef3c05483d5106a757d34
This makes the explicit synchronization unnecessary.
In the past, using `ConcurrentLongObjectMap` here led
to performance degradations (see IJPL-14861).
Now performance tests seem to indicate that there is no performance degradation
related to `ConcurrentLongObjectMap` anymore - presumably after a significant update
made to it in ite2c9a0a59.
^IJPL-161667 Fixed
GitOrigin-RevId: f1be39475667cd48de62c1b85c6cef611128fa7d
But there are some modules in .idea/compiler.xml exporting a package from a system module that is not allowed for cross-compilation mode.
GitOrigin-RevId: cf381acab50c4669d6383cbbb82eec3c194ac7df
(and move away `new LocalInspectionWrapper()` calls from class initializer to avoid fatal ClassDefNotFoundException when is throws)
GitOrigin-RevId: 7e2117288d8f475e5aae7bac830684c67858d080
`com.intellij.ide.util.projectWizard` has a thing called `com.intellij.platform.ProjectGeneratorPeer`.
It creates `JComponent` (`com.intellij.platform.ProjectGeneratorPeer.getComponent`) that is displayed on the right part of a "new project wizard.": see `com.intellij.ide.util.projectWizard.ProjectSettingsStepBase.createAdvancedSettings`.
This component is usually a form filled by a user to provide information, which is latter used by `com.intellij.platform.DirectoryProjectGenerator` to generate a new project.
Nowadays, Kotlin DSL UI is used to create such forms.
DSL UI provides a conception of validation: client calls `com.intellij.openapi.ui.DialogPanel.registerValidators` and disables "OK" button in case of validation errors.
`apply` method should also be called so a form can set values to all bound fields.
Hence, `JComponent` needs special handling if `DialogPanel`.
This logic was already implemented for `DialogWrapper`, but not for `ProjectSettingsStepBase`.
This change introduces it there.
Merge-request: IJ-MR-144050
Merged-by: Ilya Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: b9b55f5a2c3369d7a85240325df778f98bdec4fe
The behavior with the `idea.kotlin.plugin.use.k2` VM option will be the following:
- When no `idea.kotlin.plugin.use.k2` is specified in `.vmoptions`, it will be implicitly set to `true`.
- If `idea.kotlin.plugin.use.k2` is set to `true`/`false` in `.vmoptions`, this value will be used.
- If a user disables K2 mode manually in the settings, then `idea.kotlin.plugin.use.k2` will be set to `false` in `.vmoptions` and the K2 mode will be considered as disabled after a restart.
^KTIJ-30761 fixed
(cherry picked from commit bdafaad289b4e6ad3600f0653b336aefde20874f)
GitOrigin-RevId: bc0930efd86c33e5d44e5f743ea6a28d17c9b005
* replaced str(data_frame) with str(data_frame.head())
* fixed GeoPandas case
* fixed exception during formatting for get_array because of the incorrect "s" format specifier
GitOrigin-RevId: 228128000565e0d681fc79b2507be3e6bcf7958e
Avoid action calls being canceled during the patch engine rebase process due to unrelated mouse clicks.
PlatformDataKeys.EDITOR_CLICK_OVER_TEXT data context value can be sensibly retrieved only immediately after the mouse click,
which triggers the action execution. But the patch engine currently does re-calculate it during the rebase process
(via EditorClickOverTextTimestampModel) and if the newly calculated value turns out to be different from the original one, timestamp model validation in FrontendCallActionRequest.redo will cancel the action, removing it from the execution queue, even if that action isn't using that data context value in any way.
Since everything seems to work fine without EditorClickOverTextTimestampModel, we're just deleting it for now.
GitOrigin-RevId: ad53eded7a25e607a087d8c3db8bb8411c336b23