Status Update
Comments
je...@google.com <je...@google.com>
as...@google.com <as...@google.com> #2
I don't think the average developer understands the distinction between method references and method definitions in this context (inside a DEX file). I know I don't.
@jvg, can you elaborate?
be...@google.com <be...@google.com> #3
people who are looking at the bytecode in the dex to optimize their app through shrinking hopefully will learn the difference as string tables for method references between various dex files can account for quite a bit of disk space. but more importantly a definition is something you can analyze its code for where a reference you can't so the UI can be confusing without seeing the difference
be...@ridewithvia.com <be...@ridewithvia.com> #4
How about something like this?
I think having defined members be directly under the class node while references are nested in a group makes more sense.
Also note that the method refs have a
lp...@google.com <lp...@google.com>
lp...@google.com <lp...@google.com> #5
sounds reasonable to me, thanks
lp...@google.com <lp...@google.com> #6
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 4
- Android Gradle Plugin 8.8.0-alpha04
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!
js...@google.com <js...@google.com> #7
I don't see what changed in this space between 1.9.20 and 2.0.20
One major change between two is whether K2 Lint is used by default or not, and I remember there was/is an issue about binary resolution, in particular, when there are synthetic parameters generated by Compose compiler plugin. I'm not entirely sure it's properly addressed at that time or it still remains.
js...@google.com <js...@google.com> #8
I remember there was/is an issue about binary resolution, in particular, when there are synthetic parameters generated by Compose compiler plugin.
I meant this one:
js...@google.com <js...@google.com> #9
As a note, reproduced (thanks!):
.../ComposeLint86/ComposeLint86/app/src/main/java/com/example/composelint86/MainActivity.kt:35: Error: produceState calls should assign value inside the producer lambda [ProduceStateDoesNotAssignValue from androidx.compose.runtime]
val state = produceState("No-one", key1 = Unit) {
~~~~~~~~~~~~
Explanation for issues of type "ProduceStateDoesNotAssignValue":
produceState returns an observable State using values assigned inside the
producer lambda. If the lambda never assigns (i.e value = foo), then the
State will never change. Make sure to assign a value when the source you
are producing values from changes / emits a new value. For sample usage see
the produceState documentation.
Vendor: Jetpack Compose
Identifier: androidx.compose.runtime
It's supposed to be:
@Composable
fun <T> produceState(
initialValue: T,
key1: Any?,
producer: suspend ProduceStateScope<T>.() -> Unit
): State<T> { ... }
but resolved to:
@Composable
fun <T> produceState(
initialValue: T,
producer: suspend ProduceStateScope<T>.() -> Unit
): State<T> { ... }
js...@google.com <js...@google.com> #10
FYI, another instance of wrong resolution:
Description
Jetpack Compose version: 2024.09.02
Upgrading from 2024.09.00 to 02 has triggered a false positive on the following snippet with
produceState