It's basically unused and deprecated since CoroutineName is no longer used.
We practically always make a child scope with the class name.
Better to just use the class name in this case.
(cherry picked from commit 4827600b509f0ca804f5be1d05b35b11f8df470f)
(cherry picked from commit eb889a9e6dd0733a86664125feba158234b5267a)
IJ-CR-148445
GitOrigin-RevId: 5cf31226299b6ddad30f919b4ddeb36c8ae947aa
With this fix, we'll be able to add the gitlab classes to the ultimate tests classpath which will help to detect bugs caused by interfering extensions from all the plugins
(cherry picked from commit 485f87a181d8f93dc569c443fff2e7cfd70f53a5)
GitOrigin-RevId: 239dc9581d0263bca6fab4920ce5f5c1039a08cb
A dedicated optional content module was created because gitlab plugin does not have a YAML dependency
(cherry picked from commit d4cd67d49c6ac38319b17118f0c8bd44ebaeff1d)
GitOrigin-RevId: 604125375d2c3aae22ccbda74251d5468c7ad863
Toolbar was deterministically updated before adding it to the component tree.
`launch` is more likely to delay that update, though I guess it may not be 100%.
GitOrigin-RevId: 912684ffff5ade602b3b0448bdbd25a304426b23
`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
#IJPL-161647 Fixed
The old link was previously redirected until a recent update to GitLab.
This happened sometime between 17.0 and 17.4.
The fix cannot consider versions sadly, because GitLab does not
make a version visible without authentication.
As of this moment, we will break the generate functionality for
25% of users and fix it for 75%.
GitOrigin-RevId: d55f0270098a7c7a0cd8a4d152bd007b0be3eaba
Selection change and scroll is now handled purely on the VM layer which allows for better control over the state
New API is more flexible and does not depend on RefComparisonChange
Changes sorting now happens on background
GitOrigin-RevId: d6de23870105fe75087ea2967b8ef9597e65fefd
All diff requests created via `ChangeDiffRequestProducer#createRequest` will contain `DiffUserDataKeysEx.VCS_DIFF_RIGHT_CONTENT_TITLE` allowing to show short revision and file path relative to a project root
The same applies to diffs created via `MergedChangeDiffRequestProvider`
GitOrigin-RevId: 60ecb120e8751a6a211d2917838d6403a6003dfd
#IJPL-158743 Fixed
The first commit in a reversed list turned out to still be the first commit.
Sadly, the latest commit was needed, not the first.
Using the diffRefs HEAD SHA seems more appropriate than guessing
the ordering of the list in this case.
GitOrigin-RevId: a39e5c5da7065c01ce4c0721abf5cd38b67b3e6f
Simplify selector code
Check the current connection first
Show actions if there is no saved selection (#IJPL-73072 Fixed)
GitOrigin-RevId: 7a5fa5c2a5ee23be135ebc7b1ed98be6e0f41c1d
#IJPL-157434 Fixed
This should prevent READING_LENGTH exceptions caused by
JsonParsers closing the reader before reading all tokens.
Also, don't check for readiness. `ready` depends on `java.io.InputStream.available`.
But, `available` does not block to check a correct count of available bytes, so
it might return 0 even if more bytes are available still.
Probably best to read to completion regardless of readiness to avoid these errors...
Interesting note: if we use `.factory` instead of the method on `mapper`
the configurations from `genericConfig` will not be applied to the parser created.
GitOrigin-RevId: 99ff0728d1c33f59e04cf33c5c34e452b8c41d97
#IJPL-157270 Fixed
The list was loaded from back-to-front, which
the list loader did not account for.
GitOrigin-RevId: e51e1f0384c31c522f2420ca6904e0cb9f5f5816
Every time a draft note was added, all reply VMs would be re-published...
This would cause (in my case) 25-ish editors to - one after another - close and re-open.
Not great for performance in a large MR...
GitOrigin-RevId: c0d02182f1c0a1f0bcaffe8b1f829397c0bdc889
#IJPL-157270 Fixed
If these are not pushed out, a sequence like this will have incorrect results:
1. Refresh the list, 0 pages loaded, list = []
2. Update manually by adding an entry, list = [some_entry]
3. Perform some action on-server that removes the entity, but does not notify IDE.
4. Refresh the list, 0 pages loaded, list = [some_entry]
In the final step, the pagesFlow would not push out the freshly loaded list.
From the perspective of pages that's fine, but the final list is inconsistent and
should always be overridden by refreshes.
GitOrigin-RevId: 631041c137bde50e2fd8ede0d3f1dc2d3a83b564
The crux of the issue was that the data was incorrect.
UI events should be handled synchronously until the "single source of truth" is set and then that state can be propagated asynchronously.
That was not the case for tree/diff selection handlers. Selection updates were handled asynchronously which sometimes caused an updated loop while trying to synchronize two states.
#IJPL-77514 Fixed
GitOrigin-RevId: fa0e860bd893f10e09e11af49547b3844c31fd35
