Fixed
Status Update
Comments
be...@google.com <be...@google.com> #3
As well as 3.3 RC2. Can this be a regression on the Kotlin side?
be...@google.com <be...@google.com> #4
Digging into it, the problem is that early on during project creation org.jetbrains.kotlin.load.java.structure.impl.JavaPackageImpl computes all classes in a package (using the usual ModuleProductionSourcesScope) which doesn't contain our light R classes. I'm guessing this list is used for resolving references initially. Then switching to another window or creating a new file (or just waiting sometimes) triggers the Kotlin plugin to resolve references again, at which point the working codepath is used: org.jetbrains.kotlin.idea.caches.project.ModuleProductionSourceInfo enlarges scope used for the given module and this way discovers the light R classes.
We'll have to work with JetBrains on this.
We'll have to work with JetBrains on this.
ja...@google.com <ja...@google.com> #5
Adding a few more observations:
- This seems to happen only for newly created projects. If I close the newly created project and reopen it, there is no problem.
- After creating a new project, I can see the unresolved R. Besides closing and reopening the project, the only other way I have found that will get rid of the unresolved R is to switch focus to another app and back. Building the project doesn't help.
- This seems to happen only for newly created projects. If I close the newly created project and reopen it, there is no problem.
- After creating a new project, I can see the unresolved R. Besides closing and reopening the project, the only other way I have found that will get rid of the unresolved R is to switch focus to another app and back. Building the project doesn't help.
be...@google.com <be...@google.com> #6
In my experience creating a new file/class helps as well. Switching to another app triggers a VFS refresh if I understand correctly, so maybe VFS is the real trigger.
ju...@google.com <ju...@google.com> #7
Update: the fix will include a new extension point in the Kotlin plugin (see Alex's commit https://github.com/JetBrains/kotlin/commit/70bc40283ac68fe64ee3d4828913f1986b676c7a ) and its implementation in Android Studio.
Currently a module's .iml file is needed to enlarge resolve scopes with light classes. For a newly created project, resolving may happen before the .iml file is there, which is why we see unresolved R. After the .iml file is created, resolving works as expected.
Alex's commit adds a new extension point in Kotlin to enlarge scopes based on modules instead of their .iml files. Once the new API is in, we'll implement it in Android Studio.
Currently a module's .iml file is needed to enlarge resolve scopes with light classes. For a newly created project, resolving may happen before the .iml file is there, which is why we see unresolved R. After the .iml file is created, resolving works as expected.
Alex's commit adds a new extension point in Kotlin to enlarge scopes based on modules instead of their .iml files. Once the new API is in, we'll implement it in Android Studio.
be...@google.com <be...@google.com> #8
Reassigning, since you already have the CL started.
ju...@google.com <ju...@google.com> #9
Fixes merged, will be in Android Studio 3.3 RC3 and 3.4 Beta 1
Description
As before, forcing PSI to refresh one way or another "fixes" the problem.