Status Update
No update yet.
Comments
lo...@gmail.com
il...@google.com
cl...@google.com
The issue appears to be that, starting in 1.4.3, the composer used in the inlined lambda is the one captured from the parent. This is not the right one when a dialog is being presented as it is the composer for the dialog, not the dialog host.
ap...@google.com
ap...@google.com
Note to Andrei: After the aosp/2423347, the cross-inline lambda is capturing the $composer parameter from the caller instead of using the $composer parameter passed in to the lambda it was inlined into. This causes changes to be made to the composer that is not currently being used for composition which confused the recomposer.
ap...@google.com
This issue affects crossinline lambdas that are inlined into another lambda, as demonstrated by the repro case above, when the composable lambda is executed with a different composer than the function declaring the lambda. A different composer is used when a lambda is invoked in a subcomposition such as a dialog, BoxWithConstraints, and LazyColumn, amoung others.
A crossinline lambda is requred because it is illegal to invoke an non-crossinline lambda in a realized lambda (which is what crossinline allows).
The easiest work-around is to remove inline from the function which avoids the expanding of the lambda in another lambda required for this bug to manifest.
ap...@google.com
Thank you for the elaboration! The non-inline workaround is what I've been using since this code broke.
cl...@google.com
Branch: androidx-main
commit 9a5e5b6351ecaf5b888c75dfa75aea8360afc6a9
Author: Andrei Shikov <ashikov@google.com>
Date: Fri Mar 24 19:26:38 2023
Use composer of the correct scope when realizing groups
Updates function body transform to use composer parameter from target scope to realize groups. The realize call can happen outside of such scope and composer parameter is not guaranteed to be the same between scope where groups are being realize and current scope at the time of the call.
Test: CompositionTests
Fixes: 274786923
Change-Id: I0cc3c7be151edb7cbbe4114fffbde8736f7ec428
M compose/compiler/compiler-hosted/integration-tests/src/test/java/androidx/compose/compiler/plugins/kotlin/ControlFlowTransformTests.kt
M compose/compiler/compiler-hosted/integration-tests/src/test/java/androidx/compose/compiler/plugins/kotlin/FunctionBodySkippingTransformTests.kt
M compose/compiler/compiler-hosted/integration-tests/src/test/java/androidx/compose/compiler/plugins/kotlin/TargetAnnotationsTransformTests.kt
M compose/compiler/compiler-hosted/integration-tests/src/test/java/androidx/compose/compiler/plugins/kotlin/TraceInformationTest.kt
M compose/compiler/compiler-hosted/src/main/java/androidx/compose/compiler/plugins/kotlin/lower/ComposableFunctionBodyTransformer.kt
M compose/compiler/compiler-hosted/src/main/java/androidx/compose/compiler/plugins/kotlin/lower/IrSourcePrinter.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/CompositionTests.kt
Description
It is possible to open up the Navigator APIs so that they are more accessible. Specifically things like their back stack which are currently internal. Opening these up would give developers the ability to more easily create custom behavior based on our default Navigators vs always needing the implement their own.