ComposeUnstableReceiver detected on skippable functions

[kworth]

We have a few instance functions which are annotated with @Composable and the ComposeUnstableReceiver detector calls them out as problematic due to the 0th argument being unstable. But after checking our compose report we see the composable is marked as skippable. Could this be due to strong skipping? Perhaps with strong skipping this detector is no longer needed in its current form?

[ZacSweers]

Can you please include an example? This isn't really actionable with the limited context you've given 😅

[kworth]

@ZacSweers for instance, we have a fragment class with an instance function which accesses various instance properties.

class FooFragment : BaseFragment() {
    val instancePropertyA = ...
    ...
    val instancePropertyN = ...

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?,
    ) = content { 
        AppTheme { 
            InstanceFunctionComposable()
        }
    }

    @Composable
    private fun InstanceFunctionComposable() {
        ...
        // uses instancePropertyA through N in various ways
    }

    ...
}

and in the compose report it's shown as skippable

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun InstanceFunctionComposable(
  unstable <this>: FooFragment
)

We're guessing this lint detector was written before strong skipping was turned on by default, but that's only a guess that perhaps strong skipping is in play.

[blipinsk]

Imho, this rule makes little sense with Strong Skipping enabled.

To the best of my understanding, the intention behind this rule is to detect implicit unstable arguments of Composable functions that would make them not skippable, even though their explicit signature would suggest they are.

This effect wouldn't be applied to the project with Strong Skipping enabled, because unstable arguments will no longer make the function not-skippable.