Skip to content

Use Duration in runTest builders as timeout by default #3483

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Oct 21, 2022
Merged

Use Duration in runTest builders as timeout by default #3483

merged 5 commits into from
Oct 21, 2022

Conversation

hfhbd
Copy link
Contributor

@hfhbd hfhbd commented Oct 15, 2022

Duration is (finally) stable and its usage is easier to read. This change only affects the runTest builder. You could still use a Long as a timeout, but the default now uses Duration. I didn't add new tests, because runTest without a custom timeout is used a lot, and uses Duration now. Also, the timeout operator is tested with Duration too. But I am open to adding tests :)

#3135 (comment)

@qwwdfsad qwwdfsad requested a review from dkhalanskyjb October 20, 2022 16:23
@@ -22,7 +22,10 @@ public final class kotlinx/coroutines/test/TestBuildersKt {
public static final fun runTest (Lkotlinx/coroutines/test/TestScope;JLkotlin/jvm/functions/Function2;)V
public static synthetic fun runTest$default (Lkotlin/coroutines/CoroutineContext;JLkotlin/jvm/functions/Function2;ILjava/lang/Object;)V
public static synthetic fun runTest$default (Lkotlinx/coroutines/test/TestCoroutineScope;JLkotlin/jvm/functions/Function2;ILjava/lang/Object;)V
public static synthetic fun runTest$default (Lkotlinx/coroutines/test/TestScope;JLkotlin/jvm/functions/Function2;ILjava/lang/Object;)V
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unpleasant that this overload has disappeared from the resulting binary. What I think we should do instead is to make the Duration overload not have a default argument, and change the Long overload back so that it has it. From the programmer's perspective, it doesn't matter, as the behavior stays exactly the same, but preserving compatibility is nice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added, although it is experimental api.
But is there a bug in bcv? I removed the default value from runTest(Long), but there is no synthetic runTest$default function without TestScope receiver.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the source compatibility did break at least, causing the tests to fail.

Copy link
Contributor Author

@hfhbd hfhbd Oct 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which tests? I still guess, there is some bug in bcv (or I don't get binary compatibility).
Before:

  • runTest(long: default)
  • TestScope.runTest(long: default)

Now:

  • runTest(duration: default)
  • runTest(long: no default) <- I removed this default, but there is no removed line in .api
  • TestScope.runTest(duration: no default)
  • TestScope.runTest(long: default) <- added back the default

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which tests?

The tests in general didn't even compile for me, they were unable to find a runTest overload that could be invoked just as runTest { ... }.

I removed this default, but there is no removed line in .api

It's my understanding that having at least one optional parameter creates a single $default overload that allows passing all the parameters in the Object. So, since the context parameter still had a default value, the overload was created, and the binary compatibility was preserved. @qwwdfsad, could you confirm or deny this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of, except that the trailing Object parameter is never used, it's just a rudiment that we are unlikely to ever use.

Copy link
Collaborator

@dkhalanskyjb dkhalanskyjb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@dkhalanskyjb dkhalanskyjb merged commit 02bf356 into Kotlin:develop Oct 21, 2022
@hfhbd hfhbd deleted the hfhbd/duration-runTest branch October 21, 2022 13:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants