Status Update
Comments
cm...@google.com <cm...@google.com>
an...@google.com <an...@google.com>
an...@google.com <an...@google.com> #2
From debugging this, it appears the custom KotlinResolveScopeEnlarger
resolve scope enlarger that we have registered for this case is not being added to the scope when autocomplete entries are generated, resulting in the classes being omitted.
Using the example in ActivityNameBinding
.
In both K1 and K2, there is a PsiShortNamesCache
extension registered that knows about ActivityNameBinding
. During autocomplete, PsiShortNamesCache.getClassesByName()
is invoked for ActivityNameBinding
in both K1 and K2.
In K1, the scope passed into this call is a GlobalSearchScope$UnionScope
. It contains a ModuleWithDependenciesScope
, as well as several custom scopes added by various KotlinResolveScopeEnlarger
extensions. One of those custom scopes indicates that ActivityNameBinding
should be considered in scope, and eventually it is included in the autocomplete lookup.
In K2, the scope passed into this call is also a GlobalSearchScope$UnionScope
. It contains a ModuleWithDependenciesScope
and a GlobalSearchScope$FileScope
(which oddly has its myVirtualFile
field set to null). There are no custom scopes from the KotlinResolveScopeEnlarger
s.
It appears that autocomplete generation from the Kotlin plugin for K2 is ignoring scope enlargers, which means various items that should be suggested are not showing up. We will follow up to figure out how this can be fixed.
Note that the KotlinResolveScopeEnlarger
are correctly used for code that already exists in the document, which is why these classes are resolving properly once the code and import statements are already added.
ja...@google.com <ja...@google.com> #3
I am still investigating it, but I suspect the scope returned from getAdditionalResolveScope()
at ActivityNameBinding
, which is the main problem here?
See
There is a possibility that the breakpoint my experiment hit was not the instance of scope enlarger and the scope enlarger that we need was never used by K2 completion.
@andymagee, you said "During autocomplete, PsiShortNamesCache.getClassesByName()
is invoked for ActivityNameBinding
in both K1 and K2.". Could you please provide me with the stack trace by setting a breakpoint inside PsiShortNamesCache.getClassesByName()
? PsiShortNamesCache
has many children, so it is not easy to set a breakpoint. I need a hint :)
In K2, the scope passed into this call is also a GlobalSearchScope$UnionScope. It contains a ModuleWithDependenciesScope and a GlobalSearchScope$FileScope (which oddly has its myVirtualFile field set to null). There are no custom scopes from the KotlinResolveScopeEnlargers.
I also want to ask you for more information about this. How did you know this e.g., the lines for the breakpoints and how you inspect scopes?
an...@google.com <an...@google.com> #4
I am still investigating it, but I suspect the scope returned from getAdditionalResolveScope() at this line does not contain ActivityNameBinding, which is the main problem here?
Not quite. That line is never getting hit for this scenario; that's actually the problem from what I can tell. If we never add the additional scope, then the class won't be allowed. If the scope is returned, then it will include ActivityNameBinding
.
Could you please provide me with the stack trace by setting a breakpoint inside PsiShortNamesCache.getClassesByName()?
The implementation in question here is LayoutBindingShortNamesCache
I also want to ask you for more information about this. How did you know this e.g., the lines for the breakpoints and how you inspect scopes?
I just gleaned this by debugging. When LayoutBindingShortNamesCache.getClassesByName
is called with ActivityNameBinding
as the class name, I hit a breakpoint and look at the scope. For K1, the scope includes the additional scope we've added; for K2, it does not.
I also set breakpoints at getAdditionalResolveScope()
that you mentioned above. I've verified that it's called in K1 but not K2. (At least not for autocomplete - it is used correctly for highlighting, which is working as expected.)
ja...@google.com <ja...@google.com> #5
Thanks Andy! After offline-debugging it with Andy, I got some hints.
- I confirmed that the completion can access the scope
https://screenshot.googleplex.com/3wKrJQKhG9UPziv.png returned by .BindingScopeEnlarger - The reason why
does not have the scopeLayoutBindingShortNamesCache.getClassesByName() https://screenshot.googleplex.com/BpzBpfBJEaKQvVk.png :- The
analysisScope
when creatingKtSymbolFromIndexProvider
does not have the scope returned by the scope enlargerhttps://screenshot.googleplex.com/e27s638wAYoEQUU.png . - I investigated
analysisScope
and found out that it is from .IdeKotlinByModulesResolutionScopeProvider - I guess the union between the scope of
IdeKotlinByModulesResolutionScopeProvider
and the scope returned by the scope enlarger will fix this issue. I am testing it now.
- The
an...@google.com <an...@google.com> #6
Jaebaek, I'll pass this bug to you since it looks like you're pursuing a fix upstream. Please let me know if you need me to verify anything, or make any corresponding changes in studio code.
ja...@google.com <ja...@google.com> #7
Hey @jpaupore, I tried to enable the scope enlarger for K2 IDE: KaResolveExtensionProvider
.
Could you please help us how we can use KaResolveExtensionProvider
for the Android data binding completion?
pa...@gmail.com <pa...@gmail.com> #8
Are there any updates?
an...@google.com <an...@google.com> #9
We've identified the root cause and are working on a fix upstream in the Kotlin plugin.
ja...@google.com <ja...@google.com> #11
We are on discussion to land my commit for the next IntelliJ release, but I confirmed my commit fixes this issue on the upstream K2 IntelliJ with Android plugin:
The video shows the completion for a simple data binding class. I used the codelab example from
ja...@google.com <ja...@google.com> #12
I confirmed ActivityMainBinding
from
@andymagee, Could you please follow up e.g., adding unit tests to studio-main code base and close this issue after the next Android Studio release? I will reassign this issue to you.
an...@google.com <an...@google.com> #13
Agreed, the behavior is now correct as tested in the latest builds of Studio. I'll update our tests and close this issue.
an...@google.com <an...@google.com> #14
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug Feature Drop | 2024.2.2 Canary 2
- Android Gradle Plugin 8.8.0-alpha02
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
Description
Description:
When K2 Mode is enabled in Android Studio, the generated ViewBinding class cannot be imported automatically. The import statement has to be manually written, and the autocomplete feature does not function as expected. This results in an “Unresolved reference ActivityNameBinding” error.
Steps to reproduce:
Expected Result: The ViewBinding class should be automatically imported and the autocomplete feature should work correctly.
Actual Result:
The ViewBinding class is not automatically imported, the autocomplete feature does not work, and an “Unresolved reference ActivityNameBinding” error is displayed.
Please note that this issue occurs only when K2 Mode is enabled. The functionality works as expected in default mode. This issue significantly slows down the development process as developers have to manually write import statements for each ViewBinding class. I hope this issue will be addressed promptly. Thank you.