In the accessor, use GradleVersionCatalogModel (a model for a single catalog) instead of GradleVersionCatalogsModel (a model for multiple catalogs). The last one also gives access to libraries, plugins, bundles and versions - but the result is nullable. Accessing them with `!!` looks suspicious to me. Probably, it was a cause of NPE while <init> of the accessor. Anyway, the usage of GradleVersionCatalogModel looks better to me.
Code review: IJ-CR-153929
(cherry picked from commit b659570aa14e89654ece34d81f6771706760caf2)
GitOrigin-RevId: 5d8796f59f35302f6dd70a5292a8ac5c5562157e
There are some cases of NPE while <init> of the SyntheticVersionCatalogAccessor. Probably they were caused by the usage of `!!` operator with found delegate that could be null
Code review: IJ-CR-153929
(cherry picked from commit 636fc616b7148b82d645872fdef13f3b42e37c99)
GitOrigin-RevId: b3b707895ad3a5887bcde084bb35e0b87b78cc1d
Store feedback dates globally to consider several major versions and RD scenario
(cherry picked from commit 7194d98f019efecc0dbbca2e8b097be19fd11cfc)
(cherry picked from commit 8729b09d1ef21adbecbf3cb15cdd9a329046ebf3)
IJ-MR-155667
GitOrigin-RevId: f908baec1667d1e10cada10250253ce315d9ff6c
Do not show Evaluate Feedback once we have shown any CSAT notifications
(cherry picked from commit ecc781963a95bd1bec36e6f5c95ad800e81882da)
(cherry picked from commit 3e29b3f95ec161a1749a87d6bbf8e89cfb17c991)
IJ-MR-155667
GitOrigin-RevId: 872d4e474fe95e350b38b90c6d6835ff95ca2841
Do not show request feedback notifications twice
(cherry picked from commit a5e2f3278ff19918725ba77dc592347a9ffc4d93)
(cherry picked from commit e43e71f84d59e4ed26e1bef564393e44ed9045a6)
IJ-MR-155667
GitOrigin-RevId: eda1992585305691e954b7356bc2d51f91542e49
Include Host IDE information to system info of the survey
(cherry picked from commit 3822a535fffbd494de578f53e14f5a50f143b36f)
(cherry picked from commit d511b0149b34ca002bb5b6d2502f9ee08db85531)
IJ-MR-155667
GitOrigin-RevId: 58eab78bf22e1ab08b41e7cc3625d3069d4f740d
New icons for survey dialog
(cherry picked from commit 7568433465d7096c0d4338865e8f253fdf1b5cd4)
(cherry picked from commit f643f35430729f69ade739900d80105cb1249dda)
IJ-MR-155667
GitOrigin-RevId: 704a4b9d069ce6f1f9c49582ab24d649b8bf6da5
Run CSAT survey on the client side
(cherry picked from commit eb0b819f9ad4326589f013e76998dcfdd3e01b1e)
(cherry picked from commit 3ff503981d589ac352f43707abdfd3ee10736036)
IJ-MR-155667
GitOrigin-RevId: bf4044b688f353af2d5cc4f57d4e5c58161ca71a
Show next CSAT date via internal action
(cherry picked from commit 5239a1bb889eb72c03880c0e4eaaf4bf2291efd1)
(cherry picked from commit 52deaf5498f65c4d613cbef89ef972cc453105cd)
IJ-MR-155667
GitOrigin-RevId: fc385859e5bc773bbe07c4518937b82815d8d2d9
Fix hashes computation for show condition
(cherry picked from commit b07545e8cb52c438bc26c487fb9672624c3c1217)
(cherry picked from commit b34b16e13a124ec955924fa613ce72f9e06cfa9e)
IJ-MR-155667
GitOrigin-RevId: 136aa670b8a125c4c41dcb69a9047258ad8d73b8
Implemented for dialogs with yes/no/cancel, yes/no, ok/cancel actions. Any other dialogs with custom actions will return undefined exitActionType
(cherry picked from commit dd030c0a4a98c385d30c3710b3a063f500bb400e)
GitOrigin-RevId: f95022c182218f0172c7aa9a70aea38c2e44c420
Part 1, initial commit of JS part.
(cherry picked from commit 8e28858f8e6b206b044c4b7cb46a6d4932a7e29d)
(cherry picked from commit f75ec86191d844fce62acb7d0f3835349d48378d)
IJ-CR-155171
GitOrigin-RevId: 16ddacb8aa77275dd894c488d36931670e45881c
... because `JupyterCefPathHandler` is not a true "path handler" and doesn't fit into `BuiltInWebServer` security model; decoupling makes `WebServerPathHandler` easier to refactor. Besides, it delegates to an instance of `JupyterCefHttpHandler` anyway and needs an anonymous object to access `HttpRequestHandler#sendData` - so merging simplifies both the code and the logic.
(cherry picked from commit bd2122b0f2bbd2ae74da4dc2bdada6de1ccc3e1b)
(cherry picked from commit 7f157366ebb72b7083149e2a8d3a74bb17786f40)
IJ-CR-155171
GitOrigin-RevId: 8798ac40ef8abf9ed2e2994a28bd32b00ffed267
The icon was available only for version catalogs with custom location.
Code review: IJ-CR-153925
(cherry picked from commit b00d2ccd1901705489097ad193dcd97cb0fb9062)
GitOrigin-RevId: 65fbd12dbe95f05763bb8d64c65ab7c1cd67db3c
- fixes completion for "libs" `GradleVersionCatalogsCompletionTest#testCompletionForVersionCatalogProperty`
- also enables completion for all other version catalog names of a build
I realized that `GradleExtensionsContributor#processPropertiesFromCatalog` is called not only while resolving but also while completion: when only a part of catalog name was written. In this case, `name` argument is `null` and accessors should be created for all version catalogs of the corresponding build. To achieve that, I added `GradleVersionCatalogHandler#getAccessorsForAllCatalogs`.
I decided to add a separate method for getting all accessors because if I use the existing `getAccessorClass`, it would recreate `ProjectBuildModel` for each version catalog.
Code review: IJ-CR-153925
(cherry picked from commit 1250f5b3bb22b6ed1968683b0b6144418d0ad70f)
GitOrigin-RevId: 3f270387510983fbd51ba630c54a04db7d5a5025
In runtime, navigation did not work for this example:
`my<caret>Libs`.junit.jupiter
Where myLibs is a name of a version catalog defined in settings.gradle. However, navigation would work if the caret is located on `junit`.
The Interesting point is that `GradleVersionCatalogsResolveTest` has the test `testNavigationToTomlFile2` that covers this case. It was passing well because:
- in runtime, references to version catalogs are resolving using the data from the Android module. The corresponding Psi elements - StaticVersionCatalogProperty are created in GradleExtensionsContributor.kt
- in tests, references were resolved using the older approach which still works if android module does not provide version catalogs. It didn't because GroovyDslParser from the android module was not available in tests. Hence, reference was resolved using the GradleExtensionProperty PSI element created in GradleProjectExtensionContributor.kt
Code review: IJ-CR-153925
(cherry picked from commit de4bcd81a61a3bc45119857357f43a8a21a75392)
GitOrigin-RevId: a143eb4a149cea8cc549986023793912bd5c869d
The changes in this commit allow resolving references to version catalogs in included builds of a composite build if android module provides these version catalogs.
I found two existing approaches to resolve a reverence with a name of a version catalog (e.g. 'myLibs') to a TOML file:
1) Using the data from VersionCatalogsModel that is prepared at sync in `CommonGradleProjectResolverExtension#populateProjectExtraModels`.
Resolve happens in `GradleProjectExtensionContributor`. It works well for simple projects, not composite ones.
This allows navigation to a version catalog with custom location that could be specified in settings.gradle
2) Using the data from `ProjectBuildModel` that is prepared in android module. Resolve happens in `GradleExtensionsContributor`.
It works only if the code in android module correctly discovers version catalogs and provides them.
In comparison to the first approach, the data is compared not while syncing but when it is requested
Code review: IJ-CR-153925
(cherry picked from commit d2859302e5aba22413d3b1da874bff1cd15c46b2)
GitOrigin-RevId: f2f65eff37cbfed5da79cfa570fa61caafc667a2
- use language level to predict the order of comments
(cherry picked from commit e7986fcb2302dde7ad80fae9346f6a27edb576ae)
GitOrigin-RevId: f1cee2d3123a9a9845f999ac03984427799c84db
