Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ComposeUnstableReceiver detected on skippable functions #463

Open
kworth opened this issue Dec 9, 2024 · 2 comments
Open

ComposeUnstableReceiver detected on skippable functions #463

kworth opened this issue Dec 9, 2024 · 2 comments

Comments

@kworth
Copy link

kworth commented Dec 9, 2024

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
Copy link
Collaborator

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

@kworth
Copy link
Author

kworth commented Dec 9, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants