Instead, implement the functionality via Kotlin declarations. Previously, it worked in a mixed mode: some declarations were provided via LC, some via Kotlin declarations.
Additionally, this change makes Kotlin "go to symbol/class" fully dumb-aware.
New behavior:
- All declarations are now provided via plain Kotlin declarations.
- No Light Classes are used:
- To avoid using LC, `PsiShortNamesCache` is adapted in a way that it can ignore `PsiShortNamesCache` implementations which are explicitly marked as producing generated declarations instead of existing Java-based PSI like `PsiClass`, `PsiMethod`, etc.
- `KotlinShortNamesCache` is marked as such, so it's ignored.
- As no resolve is used, all Kotlin contributors work in dumb mode.
- For facade declarations, like callables (functions or properties) from a facade or a facade class itself, new Kotlin contributors create new `PsiElementBasedNavigationItem`:
- It points to the original Kotlin declaration (or to a `KtFile` in the case of a facade class itself).
- In go to class/symbol action, duplicated declarations are merged with the original ones, so they are used only for text search purposes.
- It's reflected in the tesdata updates
- `GotoSymbolModel2.getFullName` is updated so it can handle not only `PsiElement` but also a `PsiElementNavigationItem`
- Behaviour of qualified name is stabilized:
- Previously, it produced `(in Container).Foo` for LC-based classes and `Container.Foo` for plain Kotlin classes.
- Now, it always produces `Container.Foo`
- It's reflected in the tesdata updates
^KTIJ-30913 fixed
^KTIJ-30842 fixed
GitOrigin-RevId: c671f6e161dd530e19e8abbbc7046f1cd121908d
If enabled, `JavaDirectInheritorsSearcher.calculateDirectSubClasses` finds kotlin enum constants as light classes (and k1 relies on that). Based on those classes, light methods are found. But for k2 these results are redundant, because direct kotlin search is performed as well.
Regular Kotlin inheritors are not identified by the `JavaDirectInheritorsSearcher` due to their absence in the `JavaSuperClassNameOccurenceIndex`.
GitOrigin-RevId: 6ba01326975297d73ed88085154fd9706dec2b50
In this commit we implement a logical implication of the fact
that StubIndex::get is deprecated, combined with the fact that
AbstractStubIndex::get is not deprecated but calls
StubIndex::get with the exact same arguments it received. The
absence of deprecation of AbstractStubIndex::get obfuscates
the fact that we want to phase out StubIndex::get calls.
Apart from deprecating said method, we add some convenience
methods in AbstractStubIndex inheritors that ensure a few things:
- The not-deprecated and preferred StubIndex::getElements is
called with appropriate arguments, including a properly
specialised requiredClass argument.
- Shorter syntax and DRY: only 3 arguments are required to pass
into the convenience method, whereas getElements requires 2
more. These 2 arguments are fields of the AbstractStubIndex
inheritor, so it makes little sense to get them from there
and pass them into StubIndex::getElements everywhere.
Wherever we can, these convenience methods are now used.
If you have access to JetBrains internal resources, also see:
https://jetbrains.team/p/ij/reviews/112930/timelinehttps://jetbrains.slack.com/archives/CMDBCUBGE/p1691509451975689
GitOrigin-RevId: c51ef4de44aa85841799640b1ece9d291208dc69
we should not fix issues caused by wrong file type re-association instead of it we should create a mechanism to warn user about it
GitOrigin-RevId: 8e00c260d7f319828b9686fa9e8e98175ce0361a
Also: fix use scope for record components
Fixes IDEA-323449 Noticeable delay in record members highlighting when I click on them
GitOrigin-RevId: 4535c1eaa040e4ccfe61d1f214645a321438a937
Such a code is often written by mistake, and 'equals' method should be used instead. If rare cases where identity-based comparison is really needed, the code is changed to use a special Strings.areSameInstance method to make the intention explicit and avoid warnings.
GitOrigin-RevId: e89d229059157ecc9ad21d9a189f7393839ab45f
Kotlin plugin needs to contribute its directories to PackageIndex, so we need to have a public API for that. It's better to put it to Java plugin from the beginning, since corresponding functionality will be removed from the platform as soon as we get rid of platform API which allows plugins to access it.
GitOrigin-RevId: d66adf78641383312478950bb040bdf66ffd1eb2
Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: e1f798814ca7f22747768b99cbcd962d820bbfb9