CoroutineLaunchedInTestWithoutRunTest | Fails to detect coroutine usage in methods referenced from classpath

[tyvsmith]

Expected Behavior

CoroutineLaunchedInTestWithoutRunTest should detect coroutines launched both within the test file and within methods the test references outside of the target module.

Observed Behavior

It will properly catch a coroutine launched within the same test and within the same source set, but it will not detect one in a provided jar which the test references a method within. This was tested and reproduced with the detekt jar on the CLI, but should be reproduced with 2 gradle modules and a dependency.

Steps to Reproduce

Create file TestCoroutineRunTestDetekt.kt and compile to jar

class TestCoroutineRunTestDetekt {
  fun testCoroutine() {
    GlobalScope.launch {
      val foo = "foo"
      println(foo)
    }
  }
}

Create test file TestCoroutineRunTest.kt

class TestCoroutineRunTest {
  @Test
  fun testNoRunTest() {
    TestCoroutineRunTestDetekt().testCoroutine()
  }
}

Run detekt on test source with jar passed in for classpath. Note the rule doesn't catch it.

Context

The majority of our use-cases are devs with corotuines in feature code and the test doesn't enforce runTest, leading to flakey tests.

Your Environment

This was tested with the detekt.jar which we have wired up with Buck and Bazel, using type resolution.
Detekt 1.23.3 with backported rule.
Kotlin 1.9.20

[schalkms]

Copy from #7200 since the same argument applies here.

Thanks for reporting this!
I removed the bug label as this finding rather shows a current limitation of this rule. The rule in the current detekt version provides a more or less naive implementation without type and symbol solving, which this rule needs to extend the analyzed scope.

[tyvsmith]

Copy from #7200 since the same argument applies here.

@schalkms just confirming that if type resolution was supported for this rule, we would expect both usecases (the flow one in the other issue) and this one to be solved with the same root. ie, flow.launchIn under the hood would call .launch therefore it'd get caught, and we wouldn't need two fixes?