FlowCollector fun interface errors due to collect being InternalCoroutinesApi

[Tolriq]

As per the title the change in 1.6 RC2 breaks code that are copy pasted from Compose for example:

@Composable
fun <T : R, R> Flow<T>.collectAsState(
    initial: R,
    context: CoroutineContext = EmptyCoroutineContext
): State<R> = produceState(initial, this, context) {
    if (context == EmptyCoroutineContext) {
        collect { value = it }
    } else withContext(context) {
        collect { value = it }
    }
}

Will produce This is an internal kotlinx.coroutines API that should not be used from outside of kotlinx.coroutines. No compatibility guarantees are provided. It is recommended to report your use-case of internal API to kotlinx.coroutines issue tracker, so stable API could be provided instead

[ZacSweers]

#3082 removes it from some implementation classes, but I don't see how that resolves this since those implementation classes are usually opaque to users. Most code is solely collecting from a Flow itself, which still only has an @InternalCoroutinesApi-annotated collect() function. Am I missing something? It seems like the extension function was the only way to collect in the public API.

[ZacSweers]

Scratch that, I see it's merged into develop and not master. Apologies for the noise!

[bubenheimer]

Seems odd that this did not get caught by automated testing or even just building the tests, pre-release. Maybe add or change something to capture this kind of scenario?

[LouisCAD]

I think the tests run with opt-in for the @InternalCoroutinesApi.