Refactoring is done in phases:
I. Parameters
1. all references in the selected fragment are resolved and marked
2. temp anonymous function is created and the selected fragment is pasted there
3. all references in temp fragment is resolved, and for each reference which resolves differently a parameter is created
4. parameter's type is calculated based on the type of the initial expression, the minimal applicable type is to be calculated (KTIJ-29166)
5. parameter types are checked if they are visible from the new target and iff not, a conflict message is shown
II. Return type
1. Jumps & returns are analyzed to check if extraction is possible. Conflict is shown e.g., if jumps point to the different targets or jumps and returns coexist.
2. Return type is detected by the type of return statement, last selected statement or jump statement
3. Return type is checked if it's visible and iff not, a conflict message is shown
III. Generation
1. Signature is build based on defined parameters and return type; set of names is generated based on return type
2. Body is created from selected fragment with replacements for jumps/returns
IV. Duplicates are processed
1. Not implemented yet (KTIJ-29165)
^KTIJ-26164 fixed
GitOrigin-RevId: 1398693c73b2c7d5c7fe08712de0bb8777fa1810
The embedded frontend process's classpath includes plugins/cwm-plugin/lib/client/cwm-guest.jar, which contains scrambled classes of the module 'intellij.platform.commercial.license' and its libraries. Before, these modules were also included in lib/product-client.jar in the platform and scrambled (differently) there. This causes problems if different classes are renamed to the same name in these JARs during scrambling. Now these modules are excluded from lib/product-client.jar, and the runtime module repository maps them to cwm-guest.jar.
GitOrigin-RevId: a6f4503954831d250c2460a63cda20f2e8419a4d
Light descriptors for Kotlin JS projects now set up module's platform correctly.
This triggers Kotlin startup activity to create a Kotlin SDK.
This SDK should be removed after the tests to prevent leaks.
KT-65892
GitOrigin-RevId: 7fae6062ac1bc10f62f27bf9acb8dc43038e6eb8
Completion tests with a kotlin-stdlib-js with both .knm and .kjsm files.
The tests are necessary to confirm the correct handling of legacy libraries by K2 IDE.
Additionally, set up the target platform of test JS modules properly.
In K2, it's important as resolution scope is filtered based on platforms.
See IdeKotlinByModulesResolutionScopeProvider.excludeIgnoredModulesByKotlinProjectModel.
KTIJ-27566
KT-65892
GitOrigin-RevId: aa9678567e241260ef19e5f03d5dfd9b64c13fdb
.kjsm files can be present in libraries, but should be ignored
in K2 IDE mode: with KGP 1.9.0+ they are not used for compilation.
Removing decompiler from K2 is the easiest way to avoid errors caused
by duplicated declarations.
KTIJ-27566
KT-65892
GitOrigin-RevId: 8feeb9059466d27bff5bbf85bb35ca339ec409ca
To account for orientation changes, extract the code setting
the toolbar border into a function and do everything there.
It's called from the contstructor and when the orientation changes.
For the old UI it does nothing, so nothing is updated. It's the existing
behavior, so we leave it alone, even though it looks wrong, but that's
a separate issue.
GitOrigin-RevId: 7df540d66fb2d46b3b8cf880335a74fca021b089
Specifically, in SimpleToolWindowPanel and ToolWindowImpl for
painting the border and the tool window header.
To avoid double borders with ScrollableContentBorder, introduce
client properties that indicate that there's already a border nearby,
so there's no need to paint another one.
Because ScrollableContentBorder can be installed on a different
component than the scroll pane itself, also introduce a weak reference
property to indicate which target component the border is installed
on, so that all checks work properly even if the scroll pane is located
elsewhere.
GitOrigin-RevId: 602998a9346ce2503e56bc9823fb53bc6af8c248
To sort out this mess with borders and scrollable content,
we need a tool to keep track of scroll panes and their
scrolled state.
These two classes are designed just for that: one keeps
track of all scroll panes in a given container, the other
is responsible for tracking a given scroll pane and can
be used separately.
GitOrigin-RevId: f3c0c0289612457f2ffb9488ba7715a7c5b35e7f
Scheduling a runnable using scheduleWithFixedDelay wraps
it into a ContextRunnable under the hood, which captures the context,
which sometimes contains a reference to the project, creating a leak,
because it's a global app-wide thing.
Since this thing is pure UI code and doesn't require any context,
we mark it as context-aware to avoid capturing the context.
GitOrigin-RevId: 23240d901b6bae541b103563399a8030d5e4f1d6
PyCharm tests include debugger tests and project creation tests (migrated from old UI tests), AI Assistant chat tests.
GitOrigin-RevId: bf435e56d8eaa7f71d41a30a90f1a2de3a55f95e
The gap was caused by ToolWindowContentUi.TabPanel pushing the tab actions toolbar (ToolWindowHeader.toolbarWest) to the far right when the preferred width of TabPanel was larger than the sum of widths of its visible children. Since reducing the preferred width would prevent TabPanel from growing when its container becomes wider, the tab actions toolbar has been moved inside ToolWindowContentUi.TabPanel instead, This way the tab actions toolbar can be positioned adjacent to the rightmost visible tab regardless of the TabPanel's preferred width.
Code related to the tab actions toolbar has been moved from ToolWindowHeader to ToolWindowContentUi.
closes https://github.com/JetBrains/intellij-community/pull/2723
GitOrigin-RevId: c653d274efe723066325cac51e8ef48ccc87bad8
LeakHunter should trigger erasing of expired elements from WeakHashMaps
before checking them to avoid false positives.
https://jetbrains.team/p/ij/reviews/130067/files
GitOrigin-RevId: abda6fb6bc88ba3f104d25bddf9fc18405c9a4d8
- By default: VFS fails IDE startup if detects that it's storage is currently in use by another (alive) process
-`-Dvfs.fail-if-used-by-another-process=false` to disable that -- error will be logged instead
GitOrigin-RevId: 6d6707a5add2113680adc989fe14522894300d83
+ There are EA reports that could be explained by VFS storages being opened and used from >1 process. We have a protection from >1 IDE instance running -- but the protection is not 100% reliable, there are examples of >1 IDE instances running => VFS need it's own protection mechanism
GitOrigin-RevId: a784627cc5db470c09f69285b92c6bfc87ac36d0
After 1fa206f, GradleModuleData.isBuildSrcModule() would incorrectly
return false for buildSrc modules when using Gradle 8.0 and higher.
closes https://github.com/JetBrains/intellij-community/pull/2720
GitOrigin-RevId: 9d32bca27070fccbf3f4cc89c73925052ffde3b8
After 1fa206f, GradleModuleData.isBuildSrcModule() would incorrectly
return false for buildSrc modules when using Gradle 8.0 and higher.
GitOrigin-RevId: 269c66d67ff8b1f5617291ad832d169f38bbfb57
Anna Kozlova
Nikolay Chashnikov
Daniil Ovchinnikov
Toshiaki Kameyama
Petr Surkov
Edem Ibraimov
Anna.Gromova
Alexey Utkin
Pavel Kirpichenkov
Sergei Tachenov
Sergey Karpov
Elena Shaverdova
Konstantin Hudyakov
Sergey Prigogin
Petr Kudriavtsev
Ivan Pashchenko
Ruslan Cheremin
Scott Pollom