For some reason, they might be different. Probably due to incorrect PSI at the beginning of the action. In any case, document should be the source of truth, as the ModCommand will be applied to the document, rather than PSI
Fixes IDEA-359782 try postfix completion generates trailing garbage
(cherry picked from commit 292399a28d347f9b4fa22730002299d5c5b68167)
IJ-CR-147269
GitOrigin-RevId: 2ccd437d3c51c0ded16be634650ed8dfc59770b4
This reverts commit 4353aab31f4af5e3c50662669f94b823b01d3031.
- It causes a deadlock in kotlin tests: IJPL-163726
- It breaks some remote dev and code with me tests: IJPL-163871
IJPL-162151
GitOrigin-RevId: d0764a892d03104c58f8601cfbea7b35a95c71fb
Mark as internal classes which have no usages in the Marketplace and in plugins in the intellij project.
GitOrigin-RevId: 6d09e8de52d303bb8cba68f5956d2432fccae0e3
Mark as internal classes which have no usages in the Marketplace and in plugins in the intellij project.
GitOrigin-RevId: 7adfc0d130a19aed33eaa1f400bcee4c0149de86
- The function is only intended to be used by internal implementations (crucially, we don't want to expose `Object2IntMap`). Because `LibraryScopeBase` itself (despite being part of an `impl` package) is a public API, `protected` isn't enough to hide the method from the public API surface.
^KT-57733
GitOrigin-RevId: df02cbac31a4b4d6c79b966189ffc96c9d6d21ff
- Uncombined (unions of) `ModuleWithDependenciesScope` and `LibraryWithoutSourceScope` are heavily inefficient because the `contains` function requires getting the virtual file's file info for each `contains` call. When we have uncombined scopes, the file info may be requested hundreds of times. A combined scope allows getting the file info only once, and then check the roots.
- The new `ModuleSourcesScope` and the existing `LibraryWithoutSourceScope` are easily combinable, since we just have to create a combined roots map. There is no other complex magic going on to construct an efficient combined scope.
- Combined scopes have a large positive impact on performance in various test cases where we have a complex module structure with many dependencies. In fact, in some of the test cases we cannot feasibly optimize anything else from snapshots since uncombined scopes are such a huge drag on performance.
- Changing `ModuleWithDependenciesScope` and the default scope provided by `Module.moduleProductionSourceScope` and `moduleTestSourceScope` in the platform is difficult, because there are internal and external usages of `ModuleWithDependenciesScope`. It is supposed to be an implementation detail, but various usages cast `GlobalSearchScope`s to `ModuleWithDependenciesScope`s to get the module from the scope. Hence, it is currently much easier to make a change limited to the Kotlin plugin and reap the performance benefits now.
- This has the disadvantage that we'll have duplicate implementations for `AbstractVirtualFileRootsScope` and `ModuleWithDependenciesScope`, so we should still push for integration into the platform.
^KT-57733
GitOrigin-RevId: 0ca6b15f78803af9a47fd229b9b650368f95ca87
* add context to generation prompt
* implement support for html, yaml, json
* remove progress bar from generation status bar
* change UX to highlight regeneration / prompt clarification after generation done
* refactor code
GitOrigin-RevId: c87d4dd1302e44a281d86d7f7861d6b2c94ef29f
