I updated the PR from master and reworked the fix based on Evgeny Mandrikov's fix for the same problem - the only thing I found missing is that the return Unit.INSTANCE part should also be ignored.

@poseidon-mysugr

return Unit.INSTANCE part should also be ignored

It corresponds to non-suspended exit from a function, so either will be executed or function infinitely suspends. In both cases coverage is consistent with non-suspending functions, while won't after your change:

import kotlinx.coroutines.GlobalScope
import kotlinx.coroutines.launch
import kotlinx.coroutines.yield
import kotlin.concurrent.thread

object KotlinCoroutineTarget {

    private suspend fun a1() {
        b1()
    } // assertNotCovered()

    private suspend fun b1() {
        while (true) yield()
    }

    private fun a1_without_suspend() {
        b1_without_suspend()
    } // assertNotCovered()

    private fun b1_without_suspend() {
        while (true) {}
    }

    private suspend fun a2() {
        b2()
    } // assertFullyCovered()

    private suspend fun b2() {
    }

    private fun a2_without_suspend() {
        b2_without_suspend()
    } // assertFullyCovered()

    private fun b2_without_suspend() {
    }

    @JvmStatic
    fun main(args: Array<String>) {
        GlobalScope.launch { a1() }
        thread { a1_without_suspend() }
        GlobalScope.launch { a2() }
        thread { a2_without_suspend() }
        Thread.sleep(2000L)
    }

}

@Godin You're right about indefinitely suspending functions, but there is one case you've missed: The return Unit instructions are never executed if the suspend fun that is being called always suspends, but not indefinitely. For instance, if I modify your example in a very simple way:

    private suspend fun b2() {
        yield()
    }

then the return of a2 is not fully covered anymore, and cannot be, as the actual return of b2 will always be IntrinsicsKt.getCOROUTINE_SUSPENDED(), and never Unit.INSTANCE.

In some instances it's possible to write tests that trigger both paths, but if there's no control over the suspend fun that is being called (like in the example above), this may in fact be an impossible-to-reach branch, and we have a number of such examples in our code base.

I'm not sure how to filter this case while maintaining consistent behaviour with non-suspending functions, filtering the return altogether is the only thing I could come up with... Do you have a better idea?