Question: is ComposeUnstableReceiver rule aware of the runtime stability?

[francescocervone]

Hi, I'm asking because we are trying to upgrade the Slack Compose Lints from 1.2 to 1.3 and we got a bunch of ComposeUnstableReceiver issues on receivers that are actually stable or immutable.

I'm talking about the runtime stability, the one automatically inferred by the compose compiler, without manually annotating the classes. I tested it by generating the compose compiler reports (https://developer.android.com/jetpack/compose/performance/stability/diagnose#compose-compiler).

Something like this below generates a lint issue:

data class Test(val text: String)

@Composable
fun Test.test() = this

Is this the expected behavior?
If so, what is the suggested action we should take in this case in your opinion?
Should we suppress the issue or manually set the class as @Stable / @Immutable?

Thanks

[ZacSweers]

By the very nature of lint checks, it's static analysis and not runtime analysis. We could make it smarter and try to map some of the checks the compose-compiler does (which itself is also static and not truly runtime). PRs are welcome in that department.

All that said, do you know what "runtime stability" means in this case? It's not actually explained in the linked doc 🤔

[francescocervone]

do you know what "runtime stability" means in this case?

If you are talking about the line <runtime stability> = Unstable/Stable that gets generated in the reports, I believe it denotes exactly when the stability is inferred by the compose compiler.

This code below

data class InferredStable(val text: String)

data class InferredUnstable(val list: List<String>)

@Stable
data class ExplicitStable(val text: String)

@Immutable
data class ExplicitImmutable(val text: String)

generates this report

stable class InferredStable {
  stable val text: String
  <runtime stability> = Stable
}
unstable class InferredUnstable {
  unstable val list: List<String>
  <runtime stability> = Unstable
}
stable class ExplicitStable {
  stable val text: String
}
stable class ExplicitImmutable {
  stable val text: String
}

I'm just guessing based on what I observed, so I might be wrong.

[ZacSweers]

Sure, but what are the implications of that?

[francescocervone]

That if it is passed as parameter of a composable function, and all the other parameters are stable as well, the function is skippable.

From the docs:

• Stable parameters: If a composable has stable parameters that have not changed, Compose skips it.
• Unstable parameters: If a composable has unstable parameters, Compose always recomposes it when it recomposes the component's parent.

If you pass InferredUnstable to a composable function, the latter won't be skippable, while for the others in the example above it's not the case.

[ZacSweers]

I understand that, I'm referring to the implications of a parameter that is "runtime stability".

[francescocervone]

The implication of a parameter with <runtime stability> = Stable is exactly the same as an "explicitly" stable one (annotated with @Stable or @Immutable). They should be treated just the same.
Probably I'm missing your point.

[andriishpek-sigma]

In my case this rule treats all sealed classes as unstable even though in compose compiler reports they are stable.