IssueTracker

I looked into this: it seems to be specific to kotlin 2.0.0, so I guess this is K2 UAST? What I noticed:

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/runtime/runtime-lint/src/main/java/androidx/compose/runtime/lint/ProduceStateDetector.kt;l=106

For:

value = emailRepository.getEmails()

In 1.9, the value expression resolves to setValue - but in 2.0, this resolves to getValue, which seems like a bug, since the getValue operator fun shouldn't be invoked here. Jinseong, can you confirm if this change seems intended?

Thank you for looking into this first. This saved all of our time!

Kotlin version 2.0.0

You're right; this is K2 UAST, since we sync on language version now.

Re: setValue v.s. getValue for value reference in lhs,

Thanks for the pointer and investigation. This is probably one and only different behavior between K1 v.s. K2 UAST. Note that it's sort of undefined behavior if you use name reference and resolve it while its context is determined by enclosing operator. For example,

value += ...

what should we do for resolution of value? It's technically:

value = value + ...

and the getter should be invoked first. K1 UAST tended to return setter first, whereas K2 UAST returns getter first; and both go directly to compiler's resolution results, i.e., no extra handling at UAST level. I decided to let it be, while working on https://youtrack.jetbrains.com/issue/KTIJ-13815, as we now provide "multi" resolution results. Then, instead, it's up to individual detectors to adjust their logic; you may see many related changes at b/271370407 (internal link, from b/271370407#comment2, b/271370407#comment4, b/271370407#comment10, etc.).

Looking at ProduceStateDetector, in this case, relying on the resolution on name reference is subject to change, and it should rather use operator resolution. I can send out a quick fix.

I'm still reproducing this with lint 8.7.0-alpha03 and compose-runtime lint 1.7.0-beta06, I don't think this is fixed

Example (albeit somewhat more complex)

val audioPlayState by
  produceState(AudioPlayState.default(), key1 = file) {
    playbackStateUseCase(file)
      .mapNotNull { if (sliderValue.userSeek) it.mapUserSeek(sliderValue.progress) else it }
      .filterNotNull()
      .collectLatest {
        sliderValue = SliderValueChange(it.progress)
        valueRange = 0f..max(1f, it.duration)
        this.value = it
      }
  }

I marked this fixed so that the bot can chime in and said which version contains the fix. I expect it to be 8.7.0-alpha04 (cut yesterday). Stay tuned; I have a repro project, so I'll try that myself as well.

^ oops, sorry, wrong buganizer iteam :p I meant b/341316048.

Then... I have to admit I have no idea how to track the readiness of comment#4 in compose-runtime lint...

That fix (comment#4) was landed on July 1st, and for example, if I clicked latest alpha7 commits or beta05 commits, I don't think it's included? Maybe it means it's supposed to be in the next version, like 1.8.0?

Louis, can we cherry-pick that to compose-runtime 1.7.0 (if it's still in beta)?

by the time this change landed, Compose had already branched 1.7 off to a beta branch and so this landed in 1.8 ToT.

If Louis thinks this is safe to CP to 1.7 we can consider that, it looks like quite a significant change to me.

If not, the moment we get to RC with 1.7 (some ongoing issues are keeping us in beta) we will then start publishing 1.8 alpha artifacts

I don't think there is much risk here, but at the same time I don't think it is that common / meets the bar for a cherry pick. Waiting for 1.8 seems reasonable to me

It means anyone on K2 has to disable this lint check until 1.8, and for many that means probably not until early next year. If it's low risk, i think it'd be better to pull it in. Otherwise suspect most people will just disable and never think of it again

Kicking off the cherry pick process

Thanks!

I saw the fix (comment#4) is cherry-picked to compose-runtime 1.7.0-rc01: https://android.googlesource.com/platform/frameworks/support/+log/98bc1cf10201a973793b72d2ff1ae728070e47e4..d8995e2377dd4baad64b39becb6d480cadd05c86/compose/runtime

Seeing same problem here since updating to AGP 8.6.0. Kotlin 2.0.20 and Chris Banes' Compose BOM in version 2024.08.00-alpha02, which should contain compose-runtime 1.7.0-rc01.

Is this really fixed? I still see the issue with AGP 8.6.1, Compose-BOM 2024.09.03, even if using compose-runtime 1.8.0-alpha03

There was an issue here that was fixed, but it looks like there is a separate issue when using keys: please follow https://issuetracker.google.com/issues/368420773 for updates on that issue.