Try once more to restore binary compatibility in runTest

[dkhalanskyjb]

Fixes #3673

[eygraber]

I "patched" this into my project by defining that function locally, and there are still errors:

java.lang.NoSuchMethodError: 'void kotlinx.coroutines.test.TestBuildersKt.runTest(kotlinx.coroutines.test.TestScope, long, kotlin.jvm.functions.Function2)'

I was able to fix that by adding:

@Deprecated(
  "This is for binary compatibility with the `runTest` overload that existed at some point",
  level = DeprecationLevel.HIDDEN
)
@Suppress("DEPRECATION", "UNUSED_PARAMETER", "UNUSED_VARIABLE")
public fun TestScope.runTest(
  dispatchTimeoutMs: Long,
  testBody: suspend TestScope.() -> Unit
) {}

but I can't call runTest in the body since it causes a StackOverflow.

[ephemient]

Suggested change

	): TestResult = runTest(dispatchTimeoutMs, testBody)
	): TestResult = runTest(if (unused1 and 1 != 0) DEFAULT_DISPATCH_TIMEOUT_MS else dispatchTimeoutMs, testBody)

[dkhalanskyjb]

I think there's no need: if somebody did actually provide dispatchTimeoutMs, the $default overload wouldn't be chosen.

[ephemient]

Isn't that the wrong way around? We're in this function because they didn't supply all the parameters, therefore we need to fill them in.

[dkhalanskyjb]

Oh, yes, you're right, it is the other way around. Let me think about it.

[dkhalanskyjb]

You're fully correct, by decompiling this method in 1.6.4, we get

   // $FF: synthetic method
   public static void runTest$default(TestScope var0, long var1, Function2 var3, int var4, Object var5) {
      if ((var4 & 1) != 0) {
         var1 = 60000L;
      }

      TestBuildersKt.runTest(var0, var1, var3);
   }

Thanks for saving us from one more potential bugfix release!

[qwwdfsad]

Good job.

I haven't dived deep into the restored method's semantics though, it would be nice to manually check compose's library normally operates before the release

[dkhalanskyjb]

On it.

[dkhalanskyjb]

I looked into two reproducers provided to us: #3673 (comment) and #3673 (comment). On both, the issue reproduces on 1.7.0, but with a locally-published version with this patch, one project starts to build successfully, while the other changes the errors from NoSuchMethodError to some business-logic-related ones. I checked, and both do actually call the newly-provided method.

[eygraber]

Won't this still be an issue because of #3742 (comment)

[dkhalanskyjb]

@eygraber I don't understand your approach there and don't think it would work anyway, but the likely reason for StackOverflowError is that what you wrote was essentially fun runTest() = runTest(), which, yes, would cause infinite recursion and a stack overflow. Here https://github.com/Kotlin/kotlinx.coroutines/pull/3742/files, you can see that there is no recursion: runTestLegacy (with the JvmName being what it needed to be for binary compatibility) calls runTest, an entirely different function.

[eygraber]

My point was that it seems like something is also expecting this function to be present:

java.lang.NoSuchMethodError: 'void kotlinx.coroutines.test.TestBuildersKt.runTest(kotlinx.coroutines.test.TestScope, long, kotlin.jvm.functions.Function2)'

Note that it returns void, and has a different signature than the function that was restored in this PR.

[eygraber]

Tried with 1.7.1 and it works ¯_(ツ)_/¯