Use dashes instead of asterisks for lists in KDoc (#4027)

* Replace `*` with `-` everywhere in KDoc

git grep -l '\* \+\* ' | xargs -n1 sed -i 's/^\([ \t]*\* \+\)\* /\1- /'

* Fix several false positives of the regex replacement

42 files changed, 218 insertions, 218 deletions

diff --git a/buildSrc/src/main/kotlin/CommunityProjectsBuild.kt b/buildSrc/src/main/kotlin/CommunityProjectsBuild.kt
index 8cb07de1..fb86422b 100644
--- a/buildSrc/src/main/kotlin/CommunityProjectsBuild.kt
+++ b/buildSrc/src/main/kotlin/CommunityProjectsBuild.kt
@@ -17,8 +17,8 @@ private val LOGGER: Logger = Logger.getLogger("Kotlin settings logger")
  * are compatible with our libraries (aka "integration testing that substitutes lack of unit testing").
  *
  * When `build_snapshot_train` is set to true (and [isSnapshotTrainEnabled] returns `true`),
- * * `kotlin_version property` is overridden with `kotlin_snapshot_version` (see [getOverriddenKotlinVersion]),
- * * `atomicfu_version` is overwritten by TeamCity environment (AFU is built with snapshot and published to mavenLocal
+ * - `kotlin_version property` is overridden with `kotlin_snapshot_version` (see [getOverriddenKotlinVersion]),
+ * - `atomicfu_version` is overwritten by TeamCity environment (AFU is built with snapshot and published to mavenLocal
  *   as previous step or the snapshot build).
  * Additionally, mavenLocal and Sonatype snapshots are added to repository list and stress tests are disabled
  * (see [configureCommunityBuildTweaks]).
diff --git a/integration/kotlinx-coroutines-play-services/src/Tasks.kt b/integration/kotlinx-coroutines-play-services/src/Tasks.kt
index 8a1b7bdf..2035bc74 100644
--- a/integration/kotlinx-coroutines-play-services/src/Tasks.kt
+++ b/integration/kotlinx-coroutines-play-services/src/Tasks.kt
@@ -44,8 +44,8 @@ public fun <T> Task<T>.asDeferred(): Deferred<T> = asDeferredImpl(null)
 /**
  * Converts this task to an instance of [Deferred] with a [CancellationTokenSource] to control cancellation.
  * The cancellation of this function is bi-directional:
- * * If the given task is cancelled, the resulting deferred will be cancelled.
- * * If the resulting deferred is cancelled, the provided [cancellationTokenSource] will be cancelled.
+ * - If the given task is cancelled, the resulting deferred will be cancelled.
+ * - If the resulting deferred is cancelled, the provided [cancellationTokenSource] will be cancelled.
  *
  * Providing a [CancellationTokenSource] that is unrelated to the receiving [Task] is not supported and
  * leads to an unspecified behaviour.
@@ -105,9 +105,9 @@ public suspend fun <T> Task<T>.await(): T = awaitImpl(null)
  * Awaits the completion of the task that is linked to the given [CancellationTokenSource] to control cancellation.
  *
  * This suspending function is cancellable and cancellation is bi-directional:
- * * If the [Job] of the current coroutine is cancelled or completed while this suspending function is waiting, this function
+ * - If the [Job] of the current coroutine is cancelled or completed while this suspending function is waiting, this function
  * cancels the [cancellationTokenSource] and throws a [CancellationException].
- * * If the task is cancelled, then this function will throw a [CancellationException].
+ * - If the task is cancelled, then this function will throw a [CancellationException].
  *
  * Providing a [CancellationTokenSource] that is unrelated to the receiving [Task] is not supported and
  * leads to an unspecified behaviour.
diff --git a/kotlinx-coroutines-core/common/src/AbstractCoroutine.kt b/kotlinx-coroutines-core/common/src/AbstractCoroutine.kt
index d7d3b407..56e96081 100644
--- a/kotlinx-coroutines-core/common/src/AbstractCoroutine.kt
+++ b/kotlinx-coroutines-core/common/src/AbstractCoroutine.kt
@@ -16,10 +16,10 @@ import kotlin.coroutines.*
  *
  * The following methods are available for override:
  *
- * * [onStart] is invoked when the coroutine was created in non-active state and is being [started][Job.start].
- * * [onCancelling] is invoked as soon as the coroutine starts being cancelled for any reason (or completes).
- * * [onCompleted] is invoked when the coroutine completes with a value.
- * * [onCancelled] in invoked when the coroutine completes with an exception (cancelled).
+ * - [onStart] is invoked when the coroutine was created in non-active state and is being [started][Job.start].
+ * - [onCancelling] is invoked as soon as the coroutine starts being cancelled for any reason (or completes).
+ * - [onCompleted] is invoked when the coroutine completes with a value.
+ * - [onCancelled] in invoked when the coroutine completes with an exception (cancelled).
  *
  * @param parentContext the context of the parent coroutine.
  * @param initParentJob specifies whether the parent-child relationship should be instantiated directly
@@ -114,10 +114,10 @@ public abstract class AbstractCoroutine<in T>(
      * Starts this coroutine with the given code [block] and [start] strategy.
      * This function shall be invoked at most once on this coroutine.
      * 
-     * * [DEFAULT] uses [startCoroutineCancellable].
-     * * [ATOMIC] uses [startCoroutine].
-     * * [UNDISPATCHED] uses [startCoroutineUndispatched].
-     * * [LAZY] does nothing.
+     * - [DEFAULT] uses [startCoroutineCancellable].
+     * - [ATOMIC] uses [startCoroutine].
+     * - [UNDISPATCHED] uses [startCoroutineUndispatched].
+     * - [LAZY] does nothing.
      */
     public fun <R> start(start: CoroutineStart, receiver: R, block: suspend R.() -> T) {
         start(block, receiver, this)
diff --git a/kotlinx-coroutines-core/common/src/CancellableContinuation.kt b/kotlinx-coroutines-core/common/src/CancellableContinuation.kt
index 6270b22b..4b31966e 100644
--- a/kotlinx-coroutines-core/common/src/CancellableContinuation.kt
+++ b/kotlinx-coroutines-core/common/src/CancellableContinuation.kt
@@ -259,7 +259,7 @@ public interface CancellableContinuation<in T> : Continuation<T> {
  * it can be lost when the coroutine is cancelled. In order to ensure that the resource can be properly closed
  * in this case, the [CancellableContinuation] interface provides two functions.
  *
- * * [invokeOnCancellation][CancellableContinuation.invokeOnCancellation] installs a handler that is called
+ * - [invokeOnCancellation][CancellableContinuation.invokeOnCancellation] installs a handler that is called
  *   whenever a suspend coroutine is being cancelled. In addition to the example at the beginning, it can be
  *   used to ensure that a resource that was opened before the call to
  *   `suspendCancellableCoroutine` or in its body is closed in case of cancellation.
@@ -274,7 +274,7 @@ public interface CancellableContinuation<in T> : Continuation<T> {
  * }
  * ```
  *
- * * [resume(value) { ... }][CancellableContinuation.resume] method on a [CancellableContinuation] takes
+ * - [resume(value) { ... }][CancellableContinuation.resume] method on a [CancellableContinuation] takes
  *   an optional `onCancellation` block. It can be used when resuming with a resource that must be closed by
  *   the code that called the corresponding suspending function.
  *
diff --git a/kotlinx-coroutines-core/common/src/CancellableContinuationImpl.kt b/kotlinx-coroutines-core/common/src/CancellableContinuationImpl.kt
index b1f9dca6..2b039032 100644
--- a/kotlinx-coroutines-core/common/src/CancellableContinuationImpl.kt
+++ b/kotlinx-coroutines-core/common/src/CancellableContinuationImpl.kt
@@ -84,11 +84,11 @@ internal open class CancellableContinuationImpl<in T>(
      * - installParentHandle publishes this instance on T1
      *
      * T1 writes:
-     * * handle = installed; right after the installation
-     * * Shortly after: if (isComplete) handle = NonDisposableHandle
+     * - handle = installed; right after the installation
+     * - Shortly after: if (isComplete) handle = NonDisposableHandle
      *
      * Any other T writes if the parent job is cancelled in detachChild:
-     * * handle = NonDisposableHandle
+     * - handle = NonDisposableHandle
      *
      * We want to preserve a strict invariant on parentHandle transition, allowing only three of them:
      * null -> anyHandle
diff --git a/kotlinx-coroutines-core/common/src/CompletionHandler.common.kt b/kotlinx-coroutines-core/common/src/CompletionHandler.common.kt
index 31e28936..54c5a936 100644
--- a/kotlinx-coroutines-core/common/src/CompletionHandler.common.kt
+++ b/kotlinx-coroutines-core/common/src/CompletionHandler.common.kt
@@ -9,10 +9,10 @@ import kotlinx.coroutines.internal.*
  * wrapped into [CompletionHandlerException], and rethrown, potentially causing crash of unrelated code.
  *
  * The meaning of `cause` that is passed to the handler:
- * * Cause is `null` when the job has completed normally.
- * * Cause is an instance of [CancellationException] when the job was cancelled _normally_.
+ * - Cause is `null` when the job has completed normally.
+ * - Cause is an instance of [CancellationException] when the job was cancelled _normally_.
  *   **It should not be treated as an error**. In particular, it should not be reported to error logs.
- * * Otherwise, the job had _failed_.
+ * - Otherwise, the job had _failed_.
  *
  * **Note**: This type is a part of internal machinery that supports parent-child hierarchies
  * and allows for implementation of suspending functions that wait on the Job's state.
diff --git a/kotlinx-coroutines-core/common/src/CoroutineDispatcher.kt b/kotlinx-coroutines-core/common/src/CoroutineDispatcher.kt
index 7c334ed5..e9d9f19e 100644
--- a/kotlinx-coroutines-core/common/src/CoroutineDispatcher.kt
+++ b/kotlinx-coroutines-core/common/src/CoroutineDispatcher.kt
@@ -9,18 +9,18 @@ import kotlin.coroutines.*
  * The following standard implementations are provided by `kotlinx.coroutines` as properties on
  * the [Dispatchers] object:
  *
- * * [Dispatchers.Default] &mdash; is used by all standard builders if no dispatcher or any other [ContinuationInterceptor]
+ * - [Dispatchers.Default] &mdash; is used by all standard builders if no dispatcher or any other [ContinuationInterceptor]
  *   is specified in their context. It uses a common pool of shared background threads.
  *   This is an appropriate choice for compute-intensive coroutines that consume CPU resources.
- * * [Dispatchers.IO] &mdash; uses a shared pool of on-demand created threads and is designed for offloading of IO-intensive _blocking_
+ * - [Dispatchers.IO] &mdash; uses a shared pool of on-demand created threads and is designed for offloading of IO-intensive _blocking_
  *   operations (like file I/O and blocking socket I/O).
- * * [Dispatchers.Unconfined] &mdash; starts coroutine execution in the current call-frame until the first suspension,
+ * - [Dispatchers.Unconfined] &mdash; starts coroutine execution in the current call-frame until the first suspension,
  *   whereupon the coroutine builder function returns.
  *   The coroutine will later resume in whatever thread used by the
  *   corresponding suspending function, without confining it to any specific thread or pool.
  *   **The `Unconfined` dispatcher should not normally be used in code**.
- * * Private thread pools can be created with [newSingleThreadContext] and [newFixedThreadPoolContext].
- * * An arbitrary [Executor][java.util.concurrent.Executor] can be converted to a dispatcher with the [asCoroutineDispatcher] extension function.
+ * - Private thread pools can be created with [newSingleThreadContext] and [newFixedThreadPoolContext].
+ * - An arbitrary [Executor][java.util.concurrent.Executor] can be converted to a dispatcher with the [asCoroutineDispatcher] extension function.
  *
  * This class ensures that debugging facilities in [newCoroutineContext] function work properly.
  */
diff --git a/kotlinx-coroutines-core/common/src/CoroutineExceptionHandler.kt b/kotlinx-coroutines-core/common/src/CoroutineExceptionHandler.kt
index b69050af..db77c0de 100644
--- a/kotlinx-coroutines-core/common/src/CoroutineExceptionHandler.kt
+++ b/kotlinx-coroutines-core/common/src/CoroutineExceptionHandler.kt
@@ -81,9 +81,9 @@ public inline fun CoroutineExceptionHandler(crossinline handler: (CoroutineConte
  * ### Uncaught exceptions with no handler
  *
  * When no handler is installed, exception are handled in the following way:
- * * If exception is [CancellationException], it is ignored, as these exceptions are used to cancel coroutines.
- * * Otherwise, if there is a [Job] in the context, then [Job.cancel] is invoked.
- * * Otherwise, as a last resort, the exception is processed in a platform-specific manner:
+ * - If exception is [CancellationException], it is ignored, as these exceptions are used to cancel coroutines.
+ * - Otherwise, if there is a [Job] in the context, then [Job.cancel] is invoked.
+ * - Otherwise, as a last resort, the exception is processed in a platform-specific manner:
  *   - On JVM, all instances of [CoroutineExceptionHandler] found via [ServiceLoader], as well as
  *     the current thread's [Thread.uncaughtExceptionHandler], are invoked.
  *   - On Native, the whole application crashes with the exception.
diff --git a/kotlinx-coroutines-core/common/src/CoroutineScope.kt b/kotlinx-coroutines-core/common/src/CoroutineScope.kt
index e7d4446a..6b045d20 100644
--- a/kotlinx-coroutines-core/common/src/CoroutineScope.kt
+++ b/kotlinx-coroutines-core/common/src/CoroutineScope.kt
@@ -42,9 +42,9 @@ import kotlin.coroutines.intrinsics.*
  * responsible for launching child coroutines. The corresponding instance of `CoroutineScope` shall be created
  * with either `CoroutineScope()` or `MainScope()`:
  *
- * * `CoroutineScope()` uses the [context][CoroutineContext] provided to it as a parameter for its coroutines 
+ * - `CoroutineScope()` uses the [context][CoroutineContext] provided to it as a parameter for its coroutines 
  *   and adds a [Job] if one is not provided as part of the context.
- * * `MainScope()` uses [Dispatchers.Main] for its coroutines and has a [SupervisorJob].
+ * - `MainScope()` uses [Dispatchers.Main] for its coroutines and has a [SupervisorJob].
  *
  * **The key part of custom usage of `CoroutineScope` is cancelling it at the end of the lifecycle.**
  * The [CoroutineScope.cancel] extension function shall be used when the entity that was launching coroutines
diff --git a/kotlinx-coroutines-core/common/src/CoroutineStart.kt b/kotlinx-coroutines-core/common/src/CoroutineStart.kt
index 4fa5d73c..640e1562 100644
--- a/kotlinx-coroutines-core/common/src/CoroutineStart.kt
+++ b/kotlinx-coroutines-core/common/src/CoroutineStart.kt
@@ -9,10 +9,10 @@ import kotlin.coroutines.*
  * It is used in `start` parameter of [launch][CoroutineScope.launch], [async][CoroutineScope.async], and other coroutine builder functions.
  *
  * The summary of coroutine start options is:
- * * [DEFAULT] -- immediately schedules coroutine for execution according to its context;
- * * [LAZY] -- starts coroutine lazily, only when it is needed;
- * * [ATOMIC] -- atomically (in a non-cancellable way) schedules coroutine for execution according to its context;
- * * [UNDISPATCHED] -- immediately executes coroutine until its first suspension point _in the current thread_.
+ * - [DEFAULT] -- immediately schedules coroutine for execution according to its context;
+ * - [LAZY] -- starts coroutine lazily, only when it is needed;
+ * - [ATOMIC] -- atomically (in a non-cancellable way) schedules coroutine for execution according to its context;
+ * - [UNDISPATCHED] -- immediately executes coroutine until its first suspension point _in the current thread_.
  */
 public enum class CoroutineStart {
     /**
@@ -75,10 +75,10 @@ public enum class CoroutineStart {
     /**
      * Starts the corresponding block with receiver as a coroutine with this coroutine start strategy.
      *
-     * * [DEFAULT] uses [startCoroutineCancellable].
-     * * [ATOMIC] uses [startCoroutine].
-     * * [UNDISPATCHED] uses [startCoroutineUndispatched].
-     * * [LAZY] does nothing.
+     * - [DEFAULT] uses [startCoroutineCancellable].
+     * - [ATOMIC] uses [startCoroutine].
+     * - [UNDISPATCHED] uses [startCoroutineUndispatched].
+     * - [LAZY] does nothing.
      *
      * @suppress **This an internal API and should not be used from general code.**
      */
diff --git a/kotlinx-coroutines-core/common/src/EventLoop.common.kt b/kotlinx-coroutines-core/common/src/EventLoop.common.kt
index eefb1255..914cc8ea 100644
--- a/kotlinx-coroutines-core/common/src/EventLoop.common.kt
+++ b/kotlinx-coroutines-core/common/src/EventLoop.common.kt
@@ -39,9 +39,9 @@ internal abstract class EventLoop : CoroutineDispatcher() {
      * Processes next event in this event loop.
      *
      * The result of this function is to be interpreted like this:
-     * * `<= 0` -- there are potentially more events for immediate processing;
-     * * `> 0` -- a number of nanoseconds to wait for next scheduled event;
-     * * [Long.MAX_VALUE] -- no more events.
+     * - `<= 0` -- there are potentially more events for immediate processing;
+     * - `> 0` -- a number of nanoseconds to wait for next scheduled event;
+     * - [Long.MAX_VALUE] -- no more events.
      *
      * **NOTE**: Must be invoked only from the event loop's thread
      *          (no check for performance reasons, may be added in the future).
diff --git a/kotlinx-coroutines-core/common/src/Job.kt b/kotlinx-coroutines-core/common/src/Job.kt
index bac6476e..817ac4d6 100644
--- a/kotlinx-coroutines-core/common/src/Job.kt
+++ b/kotlinx-coroutines-core/common/src/Job.kt
@@ -21,9 +21,9 @@ import kotlin.jvm.*
  *
  * The most basic instances of `Job` interface are created like this:
  *
- * * **Coroutine job** is created with [launch][CoroutineScope.launch] coroutine builder.
+ * - **Coroutine job** is created with [launch][CoroutineScope.launch] coroutine builder.
  *   It runs a specified block of code and completes on completion of this block.
- * * **[CompletableJob]** is created with a `Job()` factory function.
+ * - **[CompletableJob]** is created with a `Job()` factory function.
  *   It is completed by calling [CompletableJob.complete].
  *
  * Conceptually, an execution of a job does not produce a result value. Jobs are launched solely for their
@@ -216,11 +216,11 @@ public interface Job : CoroutineContext.Element {
      *
      * A parent-child relation has the following effect:
      *
-     * * Cancellation of parent with [cancel] or its exceptional completion (failure)
+     * - Cancellation of parent with [cancel] or its exceptional completion (failure)
      *   immediately cancels all its children.
-     * * Parent cannot complete until all its children are complete. Parent waits for all its children to
+     * - Parent cannot complete until all its children are complete. Parent waits for all its children to
      *   complete in _completing_ or _cancelling_ state.
-     * * Uncaught exception in a child, by default, cancels parent. This applies even to
+     * - Uncaught exception in a child, by default, cancels parent. This applies even to
      *   children created with [async][CoroutineScope.async] and other future-like
      *   coroutine builders, even though their exceptions are caught and are encapsulated in their result.
      *   This default behavior can be overridden with [SupervisorJob].
@@ -232,9 +232,9 @@ public interface Job : CoroutineContext.Element {
      * returns a handle that should be used to detach it.
      *
      * A parent-child relation has the following effect:
-     * * Cancellation of parent with [cancel] or its exceptional completion (failure)
+     * - Cancellation of parent with [cancel] or its exceptional completion (failure)
      *   immediately cancels all its children.
-     * * Parent cannot complete until all its children are complete. Parent waits for all its children to
+     * - Parent cannot complete until all its children are complete. Parent waits for all its children to
      *   complete in _completing_ or _cancelling_ states.
      *
      * **A child must store the resulting [ChildHandle] and [dispose][DisposableHandle.dispose] the attachment
@@ -290,10 +290,10 @@ public interface Job : CoroutineContext.Element {
      * job is complete.
      *
      * The meaning of `cause` that is passed to the handler:
-     * * Cause is `null` when the job has completed normally.
-     * * Cause is an instance of [CancellationException] when the job was cancelled _normally_.
+     * - Cause is `null` when the job has completed normally.
+     * - Cause is an instance of [CancellationException] when the job was cancelled _normally_.
      *   **It should not be treated as an error**. In particular, it should not be reported to error logs.
-     * * Otherwise, the job had _failed_.
+     * - Otherwise, the job had _failed_.
      *
      * The resulting [DisposableHandle] can be used to [dispose][DisposableHandle.dispose] the
      * registration of this handler and release its memory if its invocation is no longer needed.
@@ -316,10 +316,10 @@ public interface Job : CoroutineContext.Element {
      * Otherwise, handler will be invoked once when this job is cancelled or is complete.
      *
      * The meaning of `cause` that is passed to the handler:
-     * * Cause is `null` when the job has completed normally.
-     * * Cause is an instance of [CancellationException] when the job was cancelled _normally_.
+     * - Cause is `null` when the job has completed normally.
+     * - Cause is an instance of [CancellationException] when the job was cancelled _normally_.
      *   **It should not be treated as an error**. In particular, it should not be reported to error logs.
-     * * Otherwise, the job had _failed_.
+     * - Otherwise, the job had _failed_.
      *
      * Invocation of this handler on a transition to a _cancelling_ state
      * is controlled by [onCancelling] boolean parameter.
diff --git a/kotlinx-coroutines-core/common/src/JobSupport.kt b/kotlinx-coroutines-core/common/src/JobSupport.kt
index f1d80430..2fc526a1 100644
--- a/kotlinx-coroutines-core/common/src/JobSupport.kt
+++ b/kotlinx-coroutines-core/common/src/JobSupport.kt
@@ -250,9 +250,9 @@ public open class JobSupport constructor(active: Boolean) : Job, ChildJob, Paren
         /*
          * 1) If we have non-CE, use it as root cause
          * 2) If our original cause was TCE, use *non-original* TCE because of the special nature of TCE
-         *    * It is a CE, so it's not reported by children
-         *    * The first instance (cancellation cause) is created by timeout coroutine and has no meaningful stacktrace
-         *    * The potential second instance is thrown by withTimeout lexical block itself, then it has recovered stacktrace
+         *    - It is a CE, so it's not reported by children
+         *    - The first instance (cancellation cause) is created by timeout coroutine and has no meaningful stacktrace
+         *    - The potential second instance is thrown by withTimeout lexical block itself, then it has recovered stacktrace
          * 3) Just return the very first CE
          */
         val firstNonCancellation = exceptions.firstOrNull { it !is CancellationException }
@@ -821,8 +821,8 @@ public open class JobSupport constructor(active: Boolean) : Job, ChildJob, Paren
      * Completes this job. Used by [AbstractCoroutine.resume].
      * It throws [IllegalStateException] on repeated invocation (when this job is already completing).
      * Returns:
-     * * [COMPLETING_WAITING_CHILDREN] if started waiting for children.
-     * * Final state otherwise (caller should do [afterCompletion])
+     * - [COMPLETING_WAITING_CHILDREN] if started waiting for children.
+     * - Final state otherwise (caller should do [afterCompletion])
      */
     internal fun makeCompletingOnce(proposedUpdate: Any?): Any? {
         loopOnState { state ->
@@ -986,10 +986,10 @@ public open class JobSupport constructor(active: Boolean) : Job, ChildJob, Paren
      * similarly to [invokeOnCompletion] with `onCancelling` set to `true`.
      *
      * The meaning of [cause] parameter:
-     * * Cause is `null` when the job has completed normally.
-     * * Cause is an instance of [CancellationException] when the job was cancelled _normally_.
+     * - Cause is `null` when the job has completed normally.
+     * - Cause is an instance of [CancellationException] when the job was cancelled _normally_.
      *   **It should not be treated as an error**. In particular, it should not be reported to error logs.
-     * * Otherwise, the job had been cancelled or failed with exception.
+     * - Otherwise, the job had been cancelled or failed with exception.
      *
      * The specified [cause] is not the final cancellation cause of this job.
      * A job may produce other exceptions while it is failing and the final cause might be different.
diff --git a/kotlinx-coroutines-core/common/src/Supervisor.kt b/kotlinx-coroutines-core/common/src/Supervisor.kt
index 6773da6c..8036b174 100644
--- a/kotlinx-coroutines-core/common/src/Supervisor.kt
+++ b/kotlinx-coroutines-core/common/src/Supervisor.kt
@@ -17,8 +17,8 @@ import kotlin.jvm.*
  * A failure or cancellation of a child does not cause the supervisor job to fail and does not affect its other children,
  * so a supervisor can implement a custom policy for handling failures of its children:
  *
- * * A failure of a child job that was created using [launch][CoroutineScope.launch] can be handled via [CoroutineExceptionHandler] in the context.
- * * A failure of a child job that was created using [async][CoroutineScope.async] can be handled via [Deferred.await] on the resulting deferred value.
+ * - A failure of a child job that was created using [launch][CoroutineScope.launch] can be handled via [CoroutineExceptionHandler] in the context.
+ * - A failure of a child job that was created using [async][CoroutineScope.async] can be handled via [Deferred.await] on the resulting deferred value.
  *
  * If [parent] job is specified, then this supervisor job becomes a child job of its parent and is cancelled when its
  * parent fails or is cancelled. All this supervisor's children are cancelled in this case, too. The invocation of
diff --git a/kotlinx-coroutines-core/common/src/channels/Broadcast.kt b/kotlinx-coroutines-core/common/src/channels/Broadcast.kt
index bcfab771..eba767dc 100644
--- a/kotlinx-coroutines-core/common/src/channels/Broadcast.kt
+++ b/kotlinx-coroutines-core/common/src/channels/Broadcast.kt
@@ -74,10 +74,10 @@ public fun <E> ReceiveChannel<E>.broadcast(
  * the resulting channel becomes _failed_, so that any attempt to receive from such a channel throws exception.
  *
  * The kind of the resulting channel depends on the specified [capacity] parameter:
- * * when `capacity` is positive (1 by default), but less than [UNLIMITED] -- uses [BroadcastChannel] with a buffer of given capacity,
- * * when `capacity` is [CONFLATED] -- uses [ConflatedBroadcastChannel] that conflates back-to-back sends;
+ * - when `capacity` is positive (1 by default), but less than [UNLIMITED] -- uses [BroadcastChannel] with a buffer of given capacity,
+ * - when `capacity` is [CONFLATED] -- uses [ConflatedBroadcastChannel] that conflates back-to-back sends;
  *   Note that resulting channel behaves like [ConflatedBroadcastChannel] but is not an instance of [ConflatedBroadcastChannel].
- * * otherwise -- throws [IllegalArgumentException].
+ * - otherwise -- throws [IllegalArgumentException].
  *
  * **Note:** By default, the coroutine does not start until the first subscriber appears via [BroadcastChannel.openSubscription]
  * as [start] parameter has a value of [CoroutineStart.LAZY] by default.
diff --git a/kotlinx-coroutines-core/common/src/channels/BroadcastChannel.kt b/kotlinx-coroutines-core/common/src/channels/BroadcastChannel.kt
index 059bcdcf..b90f17ec 100644
--- a/kotlinx-coroutines-core/common/src/channels/BroadcastChannel.kt
+++ b/kotlinx-coroutines-core/common/src/channels/BroadcastChannel.kt
@@ -55,11 +55,11 @@ public interface BroadcastChannel<E> : SendChannel<E> {
  *
  * The resulting channel type depends on the specified [capacity] parameter:
  *
- * * when `capacity` positive, but less than [UNLIMITED] -- creates `ArrayBroadcastChannel` with a buffer of given capacity.
+ * - when `capacity` positive, but less than [UNLIMITED] -- creates `ArrayBroadcastChannel` with a buffer of given capacity.
  *   **Note:** this channel looses all items that have been sent to it until the first subscriber appears;
- * * when `capacity` is [CONFLATED] -- creates [ConflatedBroadcastChannel] that conflates back-to-back sends;
- * * when `capacity` is [BUFFERED] -- creates `ArrayBroadcastChannel` with a default capacity.
- * * otherwise -- throws [IllegalArgumentException].
+ * - when `capacity` is [CONFLATED] -- creates [ConflatedBroadcastChannel] that conflates back-to-back sends;
+ * - when `capacity` is [BUFFERED] -- creates `ArrayBroadcastChannel` with a default capacity.
+ * - otherwise -- throws [IllegalArgumentException].
  *
  * **Note: This API is obsolete since 1.5.0 and deprecated for removal since 1.7.0**
  * It is replaced with [SharedFlow][kotlinx.coroutines.flow.SharedFlow] and [StateFlow][kotlinx.coroutines.flow.StateFlow].
diff --git a/kotlinx-coroutines-core/common/src/channels/BufferOverflow.kt b/kotlinx-coroutines-core/common/src/channels/BufferOverflow.kt
index e6263838..d4c131ef 100644
--- a/kotlinx-coroutines-core/common/src/channels/BufferOverflow.kt
+++ b/kotlinx-coroutines-core/common/src/channels/BufferOverflow.kt
@@ -4,10 +4,10 @@ package kotlinx.coroutines.channels
  * A strategy for buffer overflow handling in [channels][Channel] and [flows][kotlinx.coroutines.flow.Flow] that
  * controls what is going to be sacrificed on buffer overflow:
  *
- * * [SUSPEND] &mdash; the upstream that is [sending][SendChannel.send] or
+ * - [SUSPEND] &mdash; the upstream that is [sending][SendChannel.send] or
  *   is [emitting][kotlinx.coroutines.flow.FlowCollector.emit] a value is **suspended** while the buffer is full.
- * * [DROP_OLDEST] &mdash; drop **the oldest** value in the buffer on overflow, add the new value to the buffer, do not suspend.
- * * [DROP_LATEST] &mdash; drop **the latest** value that is being added to the buffer right now on buffer overflow
+ * - [DROP_OLDEST] &mdash; drop **the oldest** value in the buffer on overflow, add the new value to the buffer, do not suspend.
+ * - [DROP_LATEST] &mdash; drop **the latest** value that is being added to the buffer right now on buffer overflow
  *   (so that buffer contents stay the same), do not suspend.
  */
 public enum class BufferOverflow {
diff --git a/kotlinx-coroutines-core/common/src/channels/Channel.kt b/kotlinx-coroutines-core/common/src/channels/Channel.kt
index c225c083..95236349 100644
--- a/kotlinx-coroutines-core/common/src/channels/Channel.kt
+++ b/kotlinx-coroutines-core/common/src/channels/Channel.kt
@@ -143,13 +143,13 @@ public interface SendChannel<in E> {
      * This method was deprecated in the favour of [trySend].
      * It has proven itself as the most error-prone method in Channel API:
      *
-     * * `Boolean` return type creates the false sense of security, implying that `false`
+     * - `Boolean` return type creates the false sense of security, implying that `false`
      *    is returned instead of throwing an exception.
-     * * It was used mostly from non-suspending APIs where CancellationException triggered
+     * - It was used mostly from non-suspending APIs where CancellationException triggered
      *   internal failures in the application (the most common source of bugs).
-     * * Due to signature and explicit `if (ch.offer(...))` checks it was easy to
+     * - Due to signature and explicit `if (ch.offer(...))` checks it was easy to
      *   oversee such error during code review.
-     * * Its name was not aligned with the rest of the API and tried to mimic Java's queue instead.
+     * - Its name was not aligned with the rest of the API and tried to mimic Java's queue instead.
      *
      * **NB** Automatic migration provides best-effort for the user experience, but requires removal
      * or adjusting of the code that relied on the exception handling.
@@ -310,11 +310,11 @@ public interface ReceiveChannel<out E> {
      * This method was deprecated in the favour of [tryReceive].
      * It has proven itself as error-prone method in Channel API:
      *
-     * * Nullable return type creates the false sense of security, implying that `null`
+     * - Nullable return type creates the false sense of security, implying that `null`
      *    is returned instead of throwing an exception.
-     * * It was used mostly from non-suspending APIs where CancellationException triggered
+     * - It was used mostly from non-suspending APIs where CancellationException triggered
      *   internal failures in the application (the most common source of bugs).
-     * * Its name was not aligned with the rest of the API and tried to mimic Java's queue instead.
+     * - Its name was not aligned with the rest of the API and tried to mimic Java's queue instead.
      *
      * See https://github.com/Kotlin/kotlinx.coroutines/issues/974 for more context.
      *
@@ -613,35 +613,35 @@ public interface ChannelIterator<out E> {
  * The `Channel(capacity)` factory function is used to create channels of different kinds depending on
  * the value of the `capacity` integer:
  *
- * * When `capacity` is 0 &mdash; it creates a _rendezvous_ channel.
+ * - When `capacity` is 0 &mdash; it creates a _rendezvous_ channel.
  *   This channel does not have any buffer at all. An element is transferred from the sender
  *   to the receiver only when [send] and [receive] invocations meet in time (rendezvous), so [send] suspends
  *   until another coroutine invokes [receive], and [receive] suspends until another coroutine invokes [send].
  *
- * * When `capacity` is [Channel.UNLIMITED] &mdash; it creates a channel with effectively unlimited buffer.
+ * - When `capacity` is [Channel.UNLIMITED] &mdash; it creates a channel with effectively unlimited buffer.
  *   This channel has a linked-list buffer of unlimited capacity (limited only by available memory).
  *   [Sending][send] to this channel never suspends, and [trySend] always succeeds.
  *
- * * When `capacity` is [Channel.CONFLATED] &mdash; it creates a _conflated_ channel
+ * - When `capacity` is [Channel.CONFLATED] &mdash; it creates a _conflated_ channel
  *   This channel buffers at most one element and conflates all subsequent `send` and `trySend` invocations,
  *   so that the receiver always gets the last element sent.
  *   Back-to-back sent elements are conflated &mdash; only the last sent element is received,
  *   while previously sent elements **are lost**.
  *   [Sending][send] to this channel never suspends, and [trySend] always succeeds.
  *
- * * When `capacity` is positive but less than [UNLIMITED] &mdash; it creates an array-based channel with the specified capacity.
+ * - When `capacity` is positive but less than [UNLIMITED] &mdash; it creates an array-based channel with the specified capacity.
  *   This channel has an array buffer of a fixed `capacity`.
  *   [Sending][send] suspends only when the buffer is full, and [receiving][receive] suspends only when the buffer is empty.
  *
  * Buffered channels can be configured with an additional [`onBufferOverflow`][BufferOverflow] parameter. It controls the behaviour
  * of the channel's [send][Channel.send] function on buffer overflow:
  *
- * * [SUSPEND][BufferOverflow.SUSPEND] &mdash; the default, suspend `send` on buffer overflow until there is
+ * - [SUSPEND][BufferOverflow.SUSPEND] &mdash; the default, suspend `send` on buffer overflow until there is
  *   free space in the buffer.
- * * [DROP_OLDEST][BufferOverflow.DROP_OLDEST] &mdash; do not suspend the `send`, add the latest value to the buffer,
+ * - [DROP_OLDEST][BufferOverflow.DROP_OLDEST] &mdash; do not suspend the `send`, add the latest value to the buffer,
  *   drop the oldest one from the buffer.
  *   A channel with `capacity = 1` and `onBufferOverflow = DROP_OLDEST` is a _conflated_ channel.
- * * [DROP_LATEST][BufferOverflow.DROP_LATEST] &mdash; do not suspend the `send`, drop the value that is being sent,
+ * - [DROP_LATEST][BufferOverflow.DROP_LATEST] &mdash; do not suspend the `send`, drop the value that is being sent,
  *   keep the buffer contents intact.
  *
  * A non-default `onBufferOverflow` implicitly creates a channel with at least one buffered element and
@@ -672,12 +672,12 @@ public interface ChannelIterator<out E> {
  * that was sent to the channel with the call to the [send][SendChannel.send] function but failed to be delivered,
  * which can happen in the following cases:
  *
- * * When [send][SendChannel.send] operation throws an exception because it was cancelled before it had a chance to actually
+ * - When [send][SendChannel.send] operation throws an exception because it was cancelled before it had a chance to actually
  *   send the element or because the channel was [closed][SendChannel.close] or [cancelled][ReceiveChannel.cancel].
- * * When [receive][ReceiveChannel.receive], [receiveOrNull][ReceiveChannel.receiveOrNull], or [hasNext][ChannelIterator.hasNext]
+ * - When [receive][ReceiveChannel.receive], [receiveOrNull][ReceiveChannel.receiveOrNull], or [hasNext][ChannelIterator.hasNext]
  *   operation throws an exception when it had retrieved the element from the
  *   channel but was cancelled before the code following the receive call resumed.
- * * The channel was [cancelled][ReceiveChannel.cancel], in which case `onUndeliveredElement` is called on every
+ * - The channel was [cancelled][ReceiveChannel.cancel], in which case `onUndeliveredElement` is called on every
  *   remaining element in the channel's buffer.
  *
  * Note, that `onUndeliveredElement` function is called synchronously in an arbitrary context. It should be fast, non-blocking,
diff --git a/kotlinx-coroutines-core/common/src/channels/Channels.common.kt b/kotlinx-coroutines-core/common/src/channels/Channels.common.kt
index 092b3b14..f8ea04c9 100644
--- a/kotlinx-coroutines-core/common/src/channels/Channels.common.kt
+++ b/kotlinx-coroutines-core/common/src/channels/Channels.common.kt
@@ -18,9 +18,9 @@ internal const val DEFAULT_CLOSE_MESSAGE = "Channel was closed"
  * This function is deprecated in the favour of [ReceiveChannel.receiveCatching].
  *
  * This function is considered error-prone for the following reasons;
- * * Is throwing if the channel has failed even though its signature may suggest it returns 'null'
- * * It is easy to forget that exception handling still have to be explicit
- * * During code reviews and code reading, intentions of the code are frequently unclear:
+ * - Is throwing if the channel has failed even though its signature may suggest it returns 'null'
+ * - It is easy to forget that exception handling still have to be explicit
+ * - During code reviews and code reading, intentions of the code are frequently unclear:
  *   are potential exceptions ignored deliberately or not?
  *
  * @suppress doc
diff --git a/kotlinx-coroutines-core/common/src/flow/Channels.kt b/kotlinx-coroutines-core/common/src/flow/Channels.kt
index 481d057e..7bfa4996 100644
--- a/kotlinx-coroutines-core/common/src/flow/Channels.kt
+++ b/kotlinx-coroutines-core/common/src/flow/Channels.kt
@@ -48,9 +48,9 @@ private suspend fun <T> FlowCollector<T>.emitAllImpl(channel: ReceiveChannel<T>,
  *
  * ### Cancellation semantics
  *
- * * Flow collectors are cancelled when the original channel is [closed][SendChannel.close] with an exception.
- * * Flow collectors complete normally when the original channel is [closed][SendChannel.close] normally.
- * * Failure or cancellation of the flow collector does not affect the channel.
+ * - Flow collectors are cancelled when the original channel is [closed][SendChannel.close] with an exception.
+ * - Flow collectors complete normally when the original channel is [closed][SendChannel.close] normally.
+ * - Failure or cancellation of the flow collector does not affect the channel.
  *
  * ### Operator fusion
  *
@@ -69,9 +69,9 @@ public fun <T> ReceiveChannel<T>.receiveAsFlow(): Flow<T> = ChannelAsFlow(this,
  *
  * ### Cancellation semantics
  *
- * * Flow collector is cancelled when the original channel is [closed][SendChannel.close] with an exception.
- * * Flow collector completes normally when the original channel is [closed][SendChannel.close] normally.
- * * If the flow collector fails with an exception, the source channel is [cancelled][ReceiveChannel.cancel].
+ * - Flow collector is cancelled when the original channel is [closed][SendChannel.close] with an exception.
+ * - Flow collector completes normally when the original channel is [closed][SendChannel.close] normally.
+ * - If the flow collector fails with an exception, the source channel is [cancelled][ReceiveChannel.cancel].
  *
  * ### Operator fusion
  *
@@ -156,9 +156,9 @@ public fun <T> BroadcastChannel<T>.asFlow(): Flow<T> = flow {
  * This transformation is **stateful**, it launches a [produce] coroutine
  * that collects the given flow, and has the same behavior:
  *
- * * if collecting the flow throws, the channel will be closed with that exception
- * * if the [ReceiveChannel] is cancelled, the collection of the flow will be cancelled
- * * if collecting the flow completes normally, the [ReceiveChannel] will be closed normally
+ * - if collecting the flow throws, the channel will be closed with that exception
+ * - if the [ReceiveChannel] is cancelled, the collection of the flow will be cancelled
+ * - if collecting the flow completes normally, the [ReceiveChannel] will be closed normally
  *
  * A channel with [default][Channel.Factory.BUFFERED] buffer size is created.
  * Use [buffer] operator on the flow before calling `produceIn` to specify a value other than
diff --git a/kotlinx-coroutines-core/common/src/flow/Flow.kt b/kotlinx-coroutines-core/common/src/flow/Flow.kt
index 77836dc4..44e5d7fe 100644
--- a/kotlinx-coroutines-core/common/src/flow/Flow.kt
+++ b/kotlinx-coroutines-core/common/src/flow/Flow.kt
@@ -45,21 +45,21 @@ import kotlin.coroutines.*
  *
  * There are the following basic ways to create a flow:
  *
- * * [flowOf(...)][flowOf] functions to create a flow from a fixed set of values.
- * * [asFlow()][asFlow] extension functions on various types to convert them into flows.
- * * [flow { ... }][flow] builder function to construct arbitrary flows from
+ * - [flowOf(...)][flowOf] functions to create a flow from a fixed set of values.
+ * - [asFlow()][asFlow] extension functions on various types to convert them into flows.
+ * - [flow { ... }][flow] builder function to construct arbitrary flows from
  *   sequential calls to [emit][FlowCollector.emit] function.
- * * [channelFlow { ... }][channelFlow] builder function to construct arbitrary flows from
+ * - [channelFlow { ... }][channelFlow] builder function to construct arbitrary flows from
  *   potentially concurrent calls to the [send][kotlinx.coroutines.channels.SendChannel.send] function.
- * * [MutableStateFlow] and [MutableSharedFlow] define the corresponding constructor functions to create
+ * - [MutableStateFlow] and [MutableSharedFlow] define the corresponding constructor functions to create
  *   a _hot_ flow that can be directly updated.
  *
  * ### Flow constraints
  *
  * All implementations of the `Flow` interface must adhere to two key properties described in detail below:
  *
- * * Context preservation.
- * * Exception transparency.
+ * - Context preservation.
+ * - Exception transparency.
  *
  * These properties ensure the ability to perform local reasoning about the code with flows and modularize the code
  * in such a way that upstream flow emitters can be developed separately from downstream flow collectors.
diff --git a/kotlinx-coroutines-core/common/src/flow/SharedFlow.kt b/kotlinx-coroutines-core/common/src/flow/SharedFlow.kt
index 8f8bdd59..55caefda 100644
--- a/kotlinx-coroutines-core/common/src/flow/SharedFlow.kt
+++ b/kotlinx-coroutines-core/common/src/flow/SharedFlow.kt
@@ -85,11 +85,11 @@ import kotlin.jvm.*
  * and is designed to completely replace it.
  * It has the following important differences:
  *
- * * `SharedFlow` is simpler, because it does not have to implement all the [Channel] APIs, which allows
+ * - `SharedFlow` is simpler, because it does not have to implement all the [Channel] APIs, which allows
  *    for faster and simpler implementation.
- * * `SharedFlow` supports configurable replay and buffer overflow strategy.
- * * `SharedFlow` has a clear separation into a read-only `SharedFlow` interface and a [MutableSharedFlow].
- * * `SharedFlow` cannot be closed like `BroadcastChannel` and can never represent a failure.
+ * - `SharedFlow` supports configurable replay and buffer overflow strategy.
+ * - `SharedFlow` has a clear separation into a read-only `SharedFlow` interface and a [MutableSharedFlow].
+ * - `SharedFlow` cannot be closed like `BroadcastChannel` and can never represent a failure.
  *    All errors and completion signals should be explicitly _materialized_ if needed.
  *
  * To migrate [BroadcastChannel] usage to [SharedFlow], start by replacing usages of the `BroadcastChannel(capacity)`
diff --git a/kotlinx-coroutines-core/common/src/flow/SharingStarted.kt b/kotlinx-coroutines-core/common/src/flow/SharingStarted.kt
index c6c166c5..b9b73603 100644
--- a/kotlinx-coroutines-core/common/src/flow/SharingStarted.kt
+++ b/kotlinx-coroutines-core/common/src/flow/SharingStarted.kt
@@ -54,9 +54,9 @@ public enum class SharingCommand {
  * [`command`][command] flow implementation function. Back-to-back emissions of the same command have no effect.
  * Only emission of a different command has effect:
  *
- * * [START][SharingCommand.START] &mdash; the upstream flow is started.
- * * [STOP][SharingCommand.STOP] &mdash; the upstream flow is stopped.
- * * [STOP_AND_RESET_REPLAY_CACHE][SharingCommand.STOP_AND_RESET_REPLAY_CACHE] &mdash;
+ * - [START][SharingCommand.START] &mdash; the upstream flow is started.
+ * - [STOP][SharingCommand.STOP] &mdash; the upstream flow is stopped.
+ * - [STOP_AND_RESET_REPLAY_CACHE][SharingCommand.STOP_AND_RESET_REPLAY_CACHE] &mdash;
  *   the upstream flow is stopped and the [SharedFlow.replayCache] is reset to its initial state.
  *   The [shareIn] operator calls [MutableSharedFlow.resetReplayCache];
  *   the [stateIn] operator resets the value to its original `initialValue`.
@@ -86,9 +86,9 @@ public fun interface SharingStarted {
          *
          * It has the following optional parameters:
          *
-         * * [stopTimeoutMillis] &mdash; configures a delay (in milliseconds) between the disappearance of the last
+         * - [stopTimeoutMillis] &mdash; configures a delay (in milliseconds) between the disappearance of the last
          *   subscriber and the stopping of the sharing coroutine. It defaults to zero (stop immediately).
-         * * [replayExpirationMillis] &mdash; configures a delay (in milliseconds) between the stopping of
+         * - [replayExpirationMillis] &mdash; configures a delay (in milliseconds) between the stopping of
          *   the sharing coroutine and the resetting of the replay cache (which makes the cache empty for the [shareIn] operator
          *   and resets the cached value to the original `initialValue` for the [stateIn] operator).
          *   It defaults to `Long.MAX_VALUE` (keep replay cache forever, never reset buffer).
@@ -119,9 +119,9 @@ public fun interface SharingStarted {
  *
  * It has the following optional parameters:
  *
- * * [stopTimeout] &mdash; configures a delay between the disappearance of the last
+ * - [stopTimeout] &mdash; configures a delay between the disappearance of the last
  *   subscriber and the stopping of the sharing coroutine. It defaults to zero (stop immediately).
- * * [replayExpiration] &mdash; configures a delay between the stopping of
+ * - [replayExpiration] &mdash; configures a delay between the stopping of
  *   the sharing coroutine and the resetting of the replay cache (which makes the cache empty for the [shareIn] operator
  *   and resets the cached value to the original `initialValue` for the [stateIn] operator).
  *   It defaults to [Duration.INFINITE] (keep replay cache forever, never reset buffer).
diff --git a/kotlinx-coroutines-core/common/src/flow/StateFlow.kt b/kotlinx-coroutines-core/common/src/flow/StateFlow.kt
index 6e95725e..077ba837 100644
--- a/kotlinx-coroutines-core/common/src/flow/StateFlow.kt
+++ b/kotlinx-coroutines-core/common/src/flow/StateFlow.kt
@@ -86,15 +86,15 @@ import kotlin.coroutines.*
  * and is designed to completely replace it.
  * It has the following important differences:
  *
- * * `StateFlow` is simpler, because it does not have to implement all the [Channel] APIs, which allows
+ * - `StateFlow` is simpler, because it does not have to implement all the [Channel] APIs, which allows
  *   for faster, garbage-free implementation, unlike `ConflatedBroadcastChannel` implementation that
  *   allocates objects on each emitted value.
- * * `StateFlow` always has a value which can be safely read at any time via [value] property.
+ * - `StateFlow` always has a value which can be safely read at any time via [value] property.
  *    Unlike `ConflatedBroadcastChannel`, there is no way to create a state flow without a value.
- * * `StateFlow` has a clear separation into a read-only `StateFlow` interface and a [MutableStateFlow].
- * * `StateFlow` conflation is based on equality like [distinctUntilChanged] operator,
+ * - `StateFlow` has a clear separation into a read-only `StateFlow` interface and a [MutableStateFlow].
+ * - `StateFlow` conflation is based on equality like [distinctUntilChanged] operator,
  *    unlike conflation in `ConflatedBroadcastChannel` that is based on reference identity.
- * * `StateFlow` cannot be closed like `ConflatedBroadcastChannel` and can never represent a failure.
+ * - `StateFlow` cannot be closed like `ConflatedBroadcastChannel` and can never represent a failure.
  *    All errors and completion signals should be explicitly _materialized_ if needed.
  *
  * `StateFlow` is designed to better cover typical use-cases of keeping track of state changes in time, taking
@@ -243,10 +243,10 @@ private class StateFlowSlot : AbstractSharedFlowSlot<StateFlowImpl<*>>() {
     /**
      * Each slot can have one of the following states:
      *
-     * * `null` -- it is not used right now. Can [allocateLocked] to new collector.
-     * * `NONE` -- used by a collector, but neither suspended nor has pending value.
-     * * `PENDING` -- pending to process new value.
-     * * `CancellableContinuationImpl<Unit>` -- suspended waiting for new value.
+     * - `null` -- it is not used right now. Can [allocateLocked] to new collector.
+     * - `NONE` -- used by a collector, but neither suspended nor has pending value.
+     * - `PENDING` -- pending to process new value.
+     * - `CancellableContinuationImpl<Unit>` -- suspended waiting for new value.
      *
      * It is important that default `null` value is used, because there can be a race between allocation
      * of a new slot and trying to do [makePending] on this slot.
diff --git a/kotlinx-coroutines-core/common/src/flow/operators/Share.kt b/kotlinx-coroutines-core/common/src/flow/operators/Share.kt
index b4c49965..a413c90b 100644
--- a/kotlinx-coroutines-core/common/src/flow/operators/Share.kt
+++ b/kotlinx-coroutines-core/common/src/flow/operators/Share.kt
@@ -20,17 +20,17 @@ import kotlin.jvm.*
  * The starting of the sharing coroutine is controlled by the [started] parameter. The following options
  * are supported.
  *
- * * [Eagerly][SharingStarted.Eagerly] &mdash; the upstream flow is started even before the first subscriber appears. Note
+ * - [Eagerly][SharingStarted.Eagerly] &mdash; the upstream flow is started even before the first subscriber appears. Note
  *   that in this case all values emitted by the upstream beyond the most recent values as specified by
  *   [replay] parameter **will be immediately discarded**.
- * * [Lazily][SharingStarted.Lazily] &mdash; starts the upstream flow after the first subscriber appears, which guarantees
+ * - [Lazily][SharingStarted.Lazily] &mdash; starts the upstream flow after the first subscriber appears, which guarantees
  *   that this first subscriber gets all the emitted values, while subsequent subscribers are only guaranteed to
  *   get the most recent [replay] values. The upstream flow continues to be active even when all subscribers
  *   disappear, but only the most recent [replay] values are cached without subscribers.
- * * [WhileSubscribed()][SharingStarted.WhileSubscribed] &mdash; starts the upstream flow when the first subscriber
+ * - [WhileSubscribed()][SharingStarted.WhileSubscribed] &mdash; starts the upstream flow when the first subscriber
  *   appears, immediately stops when the last subscriber disappears, keeping the replay cache forever.
  *   It has additional optional configuration parameters as explained in its documentation.
- * * A custom strategy can be supplied by implementing the [SharingStarted] interface.
+ * - A custom strategy can be supplied by implementing the [SharingStarted] interface.
  *
  * The `shareIn` operator is useful in situations when there is a _cold_ flow that is expensive to create and/or
  * to maintain, but there are multiple subscribers that need to collect its values. For example, consider a
@@ -107,12 +107,12 @@ import kotlin.jvm.*
  * This default buffering can be overridden with an explicit buffer configuration by preceding the `shareIn` call
  * with [buffer] or [conflate], for example:
  *
- * * `buffer(0).shareIn(scope, started, 0)` &mdash; overrides the default buffer size and creates a [SharedFlow] without a buffer.
+ * - `buffer(0).shareIn(scope, started, 0)` &mdash; overrides the default buffer size and creates a [SharedFlow] without a buffer.
  *   Effectively, it configures sequential processing between the upstream emitter and subscribers,
  *   as the emitter is suspended until all subscribers process the value. Note, that the value is still immediately
  *   discarded when there are no subscribers.
- * * `buffer(b).shareIn(scope, started, r)` &mdash; creates a [SharedFlow] with `replay = r` and `extraBufferCapacity = b`.
- * * `conflate().shareIn(scope, started, r)` &mdash; creates a [SharedFlow] with `replay = r`, `onBufferOverflow = DROP_OLDEST`,
+ * - `buffer(b).shareIn(scope, started, r)` &mdash; creates a [SharedFlow] with `replay = r` and `extraBufferCapacity = b`.
+ * - `conflate().shareIn(scope, started, r)` &mdash; creates a [SharedFlow] with `replay = r`, `onBufferOverflow = DROP_OLDEST`,
  *   and `extraBufferCapacity = 1` when `replay == 0` to support this strategy.
  *
  * ### Operator fusion
@@ -197,9 +197,9 @@ private fun <T> CoroutineScope.launchSharing(
     /*
      * Conditional start: in the case when sharing and subscribing happens in the same dispatcher, we want to
      * have the following invariants preserved:
-     * * Delayed sharing strategies have a chance to immediately observe consecutive subscriptions.
+     * - Delayed sharing strategies have a chance to immediately observe consecutive subscriptions.
      *   E.g. in the cases like `flow.shareIn(...); flow.take(1)` we want sharing strategy to see the initial subscription
-     * * Eager sharing does not start immediately, so the subscribers have actual chance to subscribe _prior_ to sharing.
+     * - Eager sharing does not start immediately, so the subscribers have actual chance to subscribe _prior_ to sharing.
      */
     val start = if (started == SharingStarted.Eagerly) CoroutineStart.DEFAULT else CoroutineStart.UNDISPATCHED
     return launch(context, start = start) { // the single coroutine to rule the sharing
diff --git a/kotlinx-coroutines-core/common/src/internal/DispatchedTask.kt b/kotlinx-coroutines-core/common/src/internal/DispatchedTask.kt
index 92d8119d..5a38d0de 100644
--- a/kotlinx-coroutines-core/common/src/internal/DispatchedTask.kt
+++ b/kotlinx-coroutines-core/common/src/internal/DispatchedTask.kt
@@ -59,8 +59,8 @@ internal abstract class DispatchedTask<in T> internal constructor(
 
     /**
      * There are two implementations of `DispatchedTask`:
-     * * [DispatchedContinuation] keeps only simple values as successfully results.
-     * * [CancellableContinuationImpl] keeps additional data with values and overrides this method to unwrap it.
+     * - [DispatchedContinuation] keeps only simple values as successfully results.
+     * - [CancellableContinuationImpl] keeps additional data with values and overrides this method to unwrap it.
      */
     @Suppress("UNCHECKED_CAST")
     internal open fun <T> getSuccessfulResult(state: Any?): T =
@@ -68,9 +68,9 @@ internal abstract class DispatchedTask<in T> internal constructor(
 
     /**
      * There are two implementations of `DispatchedTask`:
-     * * [DispatchedContinuation] is just an intermediate storage that stores the exception that has its stack-trace
+     * - [DispatchedContinuation] is just an intermediate storage that stores the exception that has its stack-trace
      *   properly recovered and is ready to pass to the [delegate] continuation directly.
-     * * [CancellableContinuationImpl] stores raw cause of the failure in its state; when it needs to be dispatched
+     * - [CancellableContinuationImpl] stores raw cause of the failure in its state; when it needs to be dispatched
      *   its stack-trace has to be recovered, so it overrides this method for that purpose.
      */
     internal open fun getExceptionalResult(state: Any?): Throwable? =
diff --git a/kotlinx-coroutines-core/concurrent/src/MultithreadedDispatchers.common.kt b/kotlinx-coroutines-core/concurrent/src/MultithreadedDispatchers.common.kt
index 072432c0..bda8d350 100644
--- a/kotlinx-coroutines-core/concurrent/src/MultithreadedDispatchers.common.kt
+++ b/kotlinx-coroutines-core/concurrent/src/MultithreadedDispatchers.common.kt
@@ -11,9 +11,9 @@ import kotlin.jvm.*
  *
  * If the resulting dispatcher is [closed][CloseableCoroutineDispatcher.close] and
  * attempt to submit a task is made, then:
- * * On the JVM, the [Job] of the affected task is [cancelled][Job.cancel] and the task is submitted to the
+ * - On the JVM, the [Job] of the affected task is [cancelled][Job.cancel] and the task is submitted to the
  *   [Dispatchers.IO], so that the affected coroutine can clean up its resources and promptly complete.
- * * On Native, the attempt to submit a task throws an exception.
+ * - On Native, the attempt to submit a task throws an exception.
  *
  * This is a **delicate** API. The result of this method is a closeable resource with the
  * associated native resources (threads or native workers). It should not be allocated in place,
@@ -40,9 +40,9 @@ public fun newSingleThreadContext(name: String): CloseableCoroutineDispatcher =
  *
  * If the resulting dispatcher is [closed][CloseableCoroutineDispatcher.close] and
  * attempt to submit a continuation task is made,
- * * On the JVM, the [Job] of the affected task is [cancelled][Job.cancel] and the task is submitted to the
+ * - On the JVM, the [Job] of the affected task is [cancelled][Job.cancel] and the task is submitted to the
  *   [Dispatchers.IO], so that the affected coroutine can clean up its resources and promptly complete.
- * * On Native, the attempt to submit a task throws an exception.
+ * - On Native, the attempt to submit a task throws an exception.
  *
  * This is a **delicate** API. The result of this method is a closeable resource with the
  * associated native resources (threads or native workers). It should not be allocated in place,
diff --git a/kotlinx-coroutines-core/concurrent/src/internal/LockFreeLinkedList.kt b/kotlinx-coroutines-core/concurrent/src/internal/LockFreeLinkedList.kt
index 12662986..970c01fb 100644
--- a/kotlinx-coroutines-core/concurrent/src/internal/LockFreeLinkedList.kt
+++ b/kotlinx-coroutines-core/concurrent/src/internal/LockFreeLinkedList.kt
@@ -31,11 +31,11 @@ internal val CONDITION_FALSE: Any = Symbol("CONDITION_FALSE")
  * the update of the next pointer. Removed nodes have their next pointer marked with [Removed] class.
  *
  * Important notes:
- * * There are no operations to add items to left side of the list, only to the end (right side), because we cannot
+ * - There are no operations to add items to left side of the list, only to the end (right side), because we cannot
  *   efficiently linearize them with atomic multi-step head-removal operations. In short,
  *   support for [describeRemoveFirst] operation precludes ability to add items at the beginning.
- * * Previous pointers are not marked for removal. We don't support linearizable backwards traversal.
- * * Remove-helping logic is simplified and consolidated in [correctPrev] method.
+ * - Previous pointers are not marked for removal. We don't support linearizable backwards traversal.
+ * - Remove-helping logic is simplified and consolidated in [correctPrev] method.
  *
  * @suppress **This is unstable API and it is subject to change.**
  */
@@ -261,7 +261,7 @@ public actual open class LockFreeLinkedListNode {
      *
      * It returns `null` in two special cases:
      *
-     * * When this node is removed. In this case there is no need to waste time on corrections, because
+     * - When this node is removed. In this case there is no need to waste time on corrections, because
      *   remover of this node will ultimately call [correctPrev] on the next node and that will fix all
      *   the links from this node, too.
      */
diff --git a/kotlinx-coroutines-core/jvm/src/CoroutineContext.kt b/kotlinx-coroutines-core/jvm/src/CoroutineContext.kt
index fe7e22d6..ae8275f8 100644
--- a/kotlinx-coroutines-core/jvm/src/CoroutineContext.kt
+++ b/kotlinx-coroutines-core/jvm/src/CoroutineContext.kt
@@ -38,12 +38,12 @@ private fun CoroutineContext.hasCopyableElements(): Boolean =
 /**
  * Folds two contexts properly applying [CopyableThreadContextElement] rules when necessary.
  * The rules are the following:
- * * If neither context has CTCE, the sum of two contexts is returned
- * * Every CTCE from the left-hand side context that does not have a matching (by key) element from right-hand side context
+ * - If neither context has CTCE, the sum of two contexts is returned
+ * - Every CTCE from the left-hand side context that does not have a matching (by key) element from right-hand side context
  *   is [copied][CopyableThreadContextElement.copyForChild] if [isNewCoroutine] is `true`.
- * * Every CTCE from the left-hand side context that has a matching element in the right-hand side context is [merged][CopyableThreadContextElement.mergeForChild]
- * * Every CTCE from the right-hand side context that hasn't been merged is copied
- * * Everything else is added to the resulting context as is.
+ * - Every CTCE from the left-hand side context that has a matching element in the right-hand side context is [merged][CopyableThreadContextElement.mergeForChild]
+ * - Every CTCE from the right-hand side context that hasn't been merged is copied
+ * - Everything else is added to the resulting context as is.
  */
 private fun foldCopies(originalContext: CoroutineContext, appendContext: CoroutineContext, isNewCoroutine: Boolean): CoroutineContext {
     // Do we have something to copy left-hand side?
@@ -191,8 +191,8 @@ internal actual class UndispatchedCoroutine<in T>actual constructor (
      * (You can read more about this effect as "GC nepotism").
      *
      * To avoid that, we attempt to narrow down the lifetime of this thread local as much as possible:
-     * * It's never accessed when we are sure there are no thread context elements
-     * * It's cleaned up via [ThreadLocal.remove] as soon as the coroutine is suspended or finished.
+     * - It's never accessed when we are sure there are no thread context elements
+     * - It's cleaned up via [ThreadLocal.remove] as soon as the coroutine is suspended or finished.
      */
     private val threadStateToRecover = ThreadLocal<Pair<CoroutineContext, Any?>>()
 
diff --git a/kotlinx-coroutines-core/jvm/src/Debug.kt b/kotlinx-coroutines-core/jvm/src/Debug.kt
index 54f085b3..96166d14 100644
--- a/kotlinx-coroutines-core/jvm/src/Debug.kt
+++ b/kotlinx-coroutines-core/jvm/src/Debug.kt
@@ -19,9 +19,9 @@ import kotlin.internal.InlineOnly
  * Enable debugging facilities with "`kotlinx.coroutines.debug`" ([DEBUG_PROPERTY_NAME]) system property,
  * use the following values:
  *
- * * "`auto`" (default mode, [DEBUG_PROPERTY_VALUE_AUTO]) -- enabled when assertions are enabled with "`-ea`" JVM option.
- * * "`on`" ([DEBUG_PROPERTY_VALUE_ON]) or empty string -- enabled.
- * * "`off`" ([DEBUG_PROPERTY_VALUE_OFF]) -- disabled.
+ * - "`auto`" (default mode, [DEBUG_PROPERTY_VALUE_AUTO]) -- enabled when assertions are enabled with "`-ea`" JVM option.
+ * - "`on`" ([DEBUG_PROPERTY_VALUE_ON]) or empty string -- enabled.
+ * - "`off`" ([DEBUG_PROPERTY_VALUE_OFF]) -- disabled.
  *
  * Coroutine name can be explicitly assigned using [CoroutineName] context element.
  * The string "coroutine" is used as a default name.
diff --git a/kotlinx-coroutines-core/jvm/src/EventLoop.kt b/kotlinx-coroutines-core/jvm/src/EventLoop.kt
index 614acb1e..d7388ce7 100644
--- a/kotlinx-coroutines-core/jvm/src/EventLoop.kt
+++ b/kotlinx-coroutines-core/jvm/src/EventLoop.kt
@@ -29,9 +29,9 @@ internal actual fun createEventLoop(): EventLoop = BlockingEventLoop(Thread.curr
  * Processes next event in the current thread's event loop.
  *
  * The result of this function is to be interpreted like this:
- * * `<= 0` -- there are potentially more events for immediate processing;
- * * `> 0` -- a number of nanoseconds to wait for the next scheduled event;
- * * [Long.MAX_VALUE] -- no more events or no thread-local event loop.
+ * - `<= 0` -- there are potentially more events for immediate processing;
+ * - `> 0` -- a number of nanoseconds to wait for the next scheduled event;
+ * - [Long.MAX_VALUE] -- no more events or no thread-local event loop.
  *
  * Sample usage of this function:
  *
diff --git a/kotlinx-coroutines-core/jvm/src/debug/internal/DebugCoroutineInfoImpl.kt b/kotlinx-coroutines-core/jvm/src/debug/internal/DebugCoroutineInfoImpl.kt
index d2d61d34..66bb904f 100644
--- a/kotlinx-coroutines-core/jvm/src/debug/internal/DebugCoroutineInfoImpl.kt
+++ b/kotlinx-coroutines-core/jvm/src/debug/internal/DebugCoroutineInfoImpl.kt
@@ -49,9 +49,9 @@ internal class DebugCoroutineInfoImpl internal constructor(
      * How many consecutive unmatched 'updateState(RESUMED)' this object has received.
      * It can be `> 1` in two cases:
      *
-     * * The coroutine is finishing and its state is being unrolled in BaseContinuationImpl, see comment to DebugProbesImpl#callerInfoCache
+     * - The coroutine is finishing and its state is being unrolled in BaseContinuationImpl, see comment to DebugProbesImpl#callerInfoCache
      *   Such resumes are not expected to be matched and are ignored.
-     * * We encountered suspend-resume race explained above, and we do wait for a match.
+     * - We encountered suspend-resume race explained above, and we do wait for a match.
      */
     private var unmatchedResume = 0
 
diff --git a/kotlinx-coroutines-core/jvm/src/flow/internal/SafeCollector.kt b/kotlinx-coroutines-core/jvm/src/flow/internal/SafeCollector.kt
index 39fcffa7..a02feee1 100644
--- a/kotlinx-coroutines-core/jvm/src/flow/internal/SafeCollector.kt
+++ b/kotlinx-coroutines-core/jvm/src/flow/internal/SafeCollector.kt
@@ -49,8 +49,8 @@ internal actual class SafeCollector<T> actual constructor(
 
     /*
      * This property is accessed in two places:
-     * * ContinuationImpl invokes this in its `releaseIntercepted` as `context[ContinuationInterceptor]!!`
-     * * When we are within a callee, it is used to create its continuation object with this collector as completion_
+     * - ContinuationImpl invokes this in its `releaseIntercepted` as `context[ContinuationInterceptor]!!`
+     * - When we are within a callee, it is used to create its continuation object with this collector as completion_
      */
     override val context: CoroutineContext
         get() = lastEmissionContext ?: EmptyCoroutineContext
diff --git a/kotlinx-coroutines-core/jvm/src/scheduling/CoroutineScheduler.kt b/kotlinx-coroutines-core/jvm/src/scheduling/CoroutineScheduler.kt
index cfc3a459..e9d11d35 100644
--- a/kotlinx-coroutines-core/jvm/src/scheduling/CoroutineScheduler.kt
+++ b/kotlinx-coroutines-core/jvm/src/scheduling/CoroutineScheduler.kt
@@ -15,8 +15,8 @@ import kotlin.random.*
  * over worker threads, including both CPU-intensive and blocking tasks, in the most efficient manner.
  *
  * Current scheduler implementation has two optimization targets:
- * * Efficiency in the face of communication patterns (e.g. actors communicating via channel)
- * * Dynamic resizing to support blocking calls without re-dispatching coroutine to separate "blocking" thread pool.
+ * - Efficiency in the face of communication patterns (e.g. actors communicating via channel)
+ * - Dynamic resizing to support blocking calls without re-dispatching coroutine to separate "blocking" thread pool.
  *
  * ### Structural overview
  *
@@ -384,8 +384,8 @@ internal class CoroutineScheduler(
      * If `true`, then  the task will be dispatched in a FIFO manner and no additional workers will be requested,
      * but only if the current thread is a corresponding worker thread.
      * Note that caller cannot be ensured that it is being executed on worker thread for the following reasons:
-     *   * [CoroutineStart.UNDISPATCHED]
-     *   * Concurrent [close] that effectively shutdowns the worker thread
+     *   - [CoroutineStart.UNDISPATCHED]
+     *   - Concurrent [close] that effectively shutdowns the worker thread
      */
     fun dispatch(block: Runnable, taskContext: TaskContext = NonBlockingContext, tailDispatch: Boolean = false) {
         trackTask() // this is needed for virtual time support
@@ -922,8 +922,8 @@ internal class CoroutineScheduler(
             if (tryAcquireCpuPermit()) return findAnyTask(mayHaveLocalTasks)
             /*
              * If we can't acquire a CPU permit, attempt to find blocking task:
-             * * Check if our queue has one (maybe mixed in with CPU tasks)
-             * * Poll global and try steal
+             * - Check if our queue has one (maybe mixed in with CPU tasks)
+             * - Poll global and try steal
              */
             return findBlockingTask()
         }
diff --git a/kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt b/kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt
index 6c8b5616..a048d75d 100644
--- a/kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt
+++ b/kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt
@@ -113,9 +113,9 @@ internal class WorkQueue {
      * or positive value of how many nanoseconds should pass until the head of this queue will be available to steal.
      *
      * [StealingMode] controls what tasks to steal:
-     * * [STEAL_ANY] is default mode for scheduler, task from the head (in FIFO order) is stolen
-     * * [STEAL_BLOCKING_ONLY] is mode for stealing *an arbitrary* blocking task, which is used by the scheduler when helping in Dispatchers.IO mode
-     * * [STEAL_CPU_ONLY] is a kludge for `runSingleTaskFromCurrentSystemDispatcher`
+     * - [STEAL_ANY] is default mode for scheduler, task from the head (in FIFO order) is stolen
+     * - [STEAL_BLOCKING_ONLY] is mode for stealing *an arbitrary* blocking task, which is used by the scheduler when helping in Dispatchers.IO mode
+     * - [STEAL_CPU_ONLY] is a kludge for `runSingleTaskFromCurrentSystemDispatcher`
      */
     fun trySteal(stealingMode: StealingMode, stolenTaskRef: ObjectRef<Task?>): Long {
         val task = when (stealingMode) {
diff --git a/kotlinx-coroutines-core/jvm/test/internal/OnDemandAllocatingPoolLincheckTest.kt b/kotlinx-coroutines-core/jvm/test/internal/OnDemandAllocatingPoolLincheckTest.kt
index 34f9780a..77d81799 100644
--- a/kotlinx-coroutines-core/jvm/test/internal/OnDemandAllocatingPoolLincheckTest.kt
+++ b/kotlinx-coroutines-core/jvm/test/internal/OnDemandAllocatingPoolLincheckTest.kt
@@ -7,10 +7,10 @@ import org.jetbrains.kotlinx.lincheck.annotations.*
 
 /**
  * Test that:
- * * All elements allocated in [OnDemandAllocatingPool] get returned when [close] is invoked.
- * * After reaching the maximum capacity, new elements are not added.
- * * After [close] is invoked, [OnDemandAllocatingPool.allocate] returns `false`.
- * * [OnDemandAllocatingPool.close] will return an empty list after the first invocation.
+ * - All elements allocated in [OnDemandAllocatingPool] get returned when [close] is invoked.
+ * - After reaching the maximum capacity, new elements are not added.
+ * - After [close] is invoked, [OnDemandAllocatingPool.allocate] returns `false`.
+ * - [OnDemandAllocatingPool.close] will return an empty list after the first invocation.
  */
 abstract class OnDemandAllocatingPoolLincheckTest(maxCapacity: Int) : AbstractLincheckTest() {
     private val counter = atomic(0)
diff --git a/kotlinx-coroutines-debug/src/junit/junit5/CoroutinesTimeoutExtension.kt b/kotlinx-coroutines-debug/src/junit/junit5/CoroutinesTimeoutExtension.kt
index 90e015b0..f5cad666 100644
--- a/kotlinx-coroutines-debug/src/junit/junit5/CoroutinesTimeoutExtension.kt
+++ b/kotlinx-coroutines-debug/src/junit/junit5/CoroutinesTimeoutExtension.kt
@@ -108,14 +108,14 @@ internal class CoroutinesTimeoutExtension internal constructor(
      * However, extension instances can be reused with different value stores, and value stores can be reused across
      * extension instances. This leads to a tricky scheme of performing [DebugProbes.uninstall]:
      *
-     * * If neither the ownership of this instance's [DebugProbes] was yet passed nor there is any cleanup procedure
+     * - If neither the ownership of this instance's [DebugProbes] was yet passed nor there is any cleanup procedure
      *   stored, it means that we can just store our cleanup procedure, passing the ownership.
-     * * If the ownership was not yet passed, but a cleanup procedure is already stored, we can't just replace it with
+     * - If the ownership was not yet passed, but a cleanup procedure is already stored, we can't just replace it with
      *   another one, as this would lead to imbalance between [DebugProbes.install] and [DebugProbes.uninstall].
      *   Instead, we know that this extension context will at least outlive this use of this instance, so some debug
      *   probes other than the ones from our constructor are already installed and won't be uninstalled during our
      *   operation. We simply uninstall the debug probes that were installed in our constructor.
-     * * If the ownership was passed, but the store is empty, it means that this test instance is reused and, possibly,
+     * - If the ownership was passed, but the store is empty, it means that this test instance is reused and, possibly,
      *   the debug probes installed in its constructor were already uninstalled. This means that we have to install them
      *   anew and store an uninstaller.
      */
diff --git a/kotlinx-coroutines-test/common/src/TestBuilders.kt b/kotlinx-coroutines-test/common/src/TestBuilders.kt
index 1a763b6d..4fa86859 100644
--- a/kotlinx-coroutines-test/common/src/TestBuilders.kt
+++ b/kotlinx-coroutines-test/common/src/TestBuilders.kt
@@ -15,17 +15,17 @@ import kotlin.time.Duration.Companion.seconds
 /**
  * A test result.
  *
- * * On JVM and Native, this resolves to [Unit], representing the fact that tests are run in a blocking manner on these
+ * - On JVM and Native, this resolves to [Unit], representing the fact that tests are run in a blocking manner on these
  *   platforms: a call to a function returning a [TestResult] will simply execute the test inside it.
- * * On JS, this is a `Promise`, which reflects the fact that the test-running function does not wait for a test to
+ * - On JS, this is a `Promise`, which reflects the fact that the test-running function does not wait for a test to
  *   finish. The JS test frameworks typically support returning `Promise` from a test and will correctly handle it.
  *
  * Because of the behavior on JS, extra care must be taken when writing multiplatform tests to avoid losing test errors:
- * * Don't do anything after running the functions returning a [TestResult]. On JS, this code will execute *before* the
+ * - Don't do anything after running the functions returning a [TestResult]. On JS, this code will execute *before* the
  *   test finishes.
- * * As a corollary, don't run functions returning a [TestResult] more than once per test. The only valid thing to do
+ * - As a corollary, don't run functions returning a [TestResult] more than once per test. The only valid thing to do
  *   with a [TestResult] is to immediately `return` it from a test.
- * * Don't nest functions returning a [TestResult].
+ * - Don't nest functions returning a [TestResult].
  */
 @Suppress("NO_ACTUAL_FOR_EXPECT")
 public expect class TestResult
@@ -462,11 +462,11 @@ internal suspend fun <T : AbstractCoroutine<Unit>> CoroutineScope.runTestCorouti
      * 1. Try running the work that the scheduler knows about, both background and foreground.
      *
      * 2. Wait until we run out of foreground work to do. This could mean one of the following:
-     *    * The main coroutine is already completed. This is checked separately; then we leave the procedure.
-     *    * It's switched to another dispatcher that doesn't know about the [TestCoroutineScheduler].
-     *    * Generally, it's waiting for something external (like a network request, or just an arbitrary callback).
-     *    * The test simply hanged.
-     *    * The main coroutine is waiting for some background work.
+     *    - The main coroutine is already completed. This is checked separately; then we leave the procedure.
+     *    - It's switched to another dispatcher that doesn't know about the [TestCoroutineScheduler].
+     *    - Generally, it's waiting for something external (like a network request, or just an arbitrary callback).
+     *    - The test simply hanged.
+     *    - The main coroutine is waiting for some background work.
      *
      * 3. We await progress from things that are not the code under test:
      *    the background work that the scheduler knows about, the external callbacks,
diff --git a/kotlinx-coroutines-test/common/src/TestCoroutineScheduler.kt b/kotlinx-coroutines-test/common/src/TestCoroutineScheduler.kt
index a4d3ee51..ba46d17c 100644
--- a/kotlinx-coroutines-test/common/src/TestCoroutineScheduler.kt
+++ b/kotlinx-coroutines-test/common/src/TestCoroutineScheduler.kt
@@ -138,13 +138,13 @@ public class TestCoroutineScheduler : AbstractCoroutineContextElement(TestCorout
      * scheduled tasks in the meantime.
      *
      * Breaking changes from [TestCoroutineDispatcher.advanceTimeBy]:
-     * * Intentionally doesn't return a `Long` value, as its use cases are unclear. We may restore it in the future;
+     * - Intentionally doesn't return a `Long` value, as its use cases are unclear. We may restore it in the future;
      *   please describe your use cases at [the issue tracker](https://github.com/Kotlin/kotlinx.coroutines/issues/).
      *   For now, it's possible to query [currentTime] before and after execution of this method, to the same effect.
-     * * It doesn't run the tasks that are scheduled at exactly [currentTime] + [delayTimeMillis]. For example,
+     * - It doesn't run the tasks that are scheduled at exactly [currentTime] + [delayTimeMillis]. For example,
      *   advancing the time by one millisecond used to run the tasks at the current millisecond *and* the next
      *   millisecond, but now will stop just before executing any task starting at the next millisecond.
-     * * Overflowing the target time used to lead to nothing being done, but will now run the tasks scheduled at up to
+     * - Overflowing the target time used to lead to nothing being done, but will now run the tasks scheduled at up to
      *   (but not including) [Long.MAX_VALUE].
      *
      * @throws IllegalArgumentException if passed a negative [delay][delayTimeMillis].
diff --git a/kotlinx-coroutines-test/common/src/TestDispatcher.kt b/kotlinx-coroutines-test/common/src/TestDispatcher.kt
index 3e8803bf..a4427a1a 100644
--- a/kotlinx-coroutines-test/common/src/TestDispatcher.kt
+++ b/kotlinx-coroutines-test/common/src/TestDispatcher.kt
@@ -9,8 +9,8 @@ import kotlin.time.*
  * A test dispatcher that can interface with a [TestCoroutineScheduler].
  *
  * The available implementations are:
- * * [StandardTestDispatcher] is a dispatcher that places new tasks into a queue.
- * * [UnconfinedTestDispatcher] is a dispatcher that behaves like [Dispatchers.Unconfined] while allowing to control
+ * - [StandardTestDispatcher] is a dispatcher that places new tasks into a queue.
+ * - [UnconfinedTestDispatcher] is a dispatcher that behaves like [Dispatchers.Unconfined] while allowing to control
  *   the virtual time.
  */
 @Suppress("INVISIBLE_REFERENCE")
diff --git a/kotlinx-coroutines-test/common/src/TestScope.kt b/kotlinx-coroutines-test/common/src/TestScope.kt
index 9ecea83c..f6e69510 100644
--- a/kotlinx-coroutines-test/common/src/TestScope.kt
+++ b/kotlinx-coroutines-test/common/src/TestScope.kt
@@ -10,12 +10,12 @@ import kotlin.time.*
  * A coroutine scope that for launching test coroutines.
  *
  * The scope provides the following functionality:
- * * The [coroutineContext] includes a [coroutine dispatcher][TestDispatcher] that supports delay-skipping, using
+ * - The [coroutineContext] includes a [coroutine dispatcher][TestDispatcher] that supports delay-skipping, using
  *   a [TestCoroutineScheduler] for orchestrating the virtual time.
  *   This scheduler is also available via the [testScheduler] property, and some helper extension
  *   methods are defined to more conveniently interact with it: see [TestScope.currentTime], [TestScope.runCurrent],
  *   [TestScope.advanceTimeBy], and [TestScope.advanceUntilIdle].
- * * When inside [runTest], uncaught exceptions from the child coroutines of this scope will be reported at the end of
+ * - When inside [runTest], uncaught exceptions from the child coroutines of this scope will be reported at the end of
  *   the test.
  *   It is invalid for child coroutines to throw uncaught exceptions when outside the call to [TestScope.runTest]:
  *   the only guarantee in this case is the best effort to deliver the exception.
@@ -25,16 +25,16 @@ import kotlin.time.*
  *
  * #### Differences from the deprecated [TestCoroutineScope]
  *
- * * This doesn't provide an equivalent of [TestCoroutineScope.cleanupTestCoroutines], and so can't be used as a
+ * - This doesn't provide an equivalent of [TestCoroutineScope.cleanupTestCoroutines], and so can't be used as a
  *   standalone mechanism for writing tests: it does require that [runTest] is eventually called.
  *   The reason for this is that a proper cleanup procedure that supports using non-test dispatchers and arbitrary
  *   coroutine suspensions would be equivalent to [runTest], but would also be more error-prone, due to the potential
  *   for forgetting to perform the cleanup.
- * * [TestCoroutineScope.advanceTimeBy] also calls [TestCoroutineScheduler.runCurrent] after advancing the virtual time.
- * * No support for dispatcher pausing, like [DelayController] allows. [TestCoroutineDispatcher], which supported
+ * - [TestCoroutineScope.advanceTimeBy] also calls [TestCoroutineScheduler.runCurrent] after advancing the virtual time.
+ * - No support for dispatcher pausing, like [DelayController] allows. [TestCoroutineDispatcher], which supported
  *   pausing, is deprecated; now, instead of pausing a dispatcher, one can use [withContext] to run a dispatcher that's
  *   paused by default, like [StandardTestDispatcher].
- * * No access to the list of unhandled exceptions.
+ * - No access to the list of unhandled exceptions.
  */
 public sealed interface TestScope : CoroutineScope {
     /**
@@ -138,20 +138,20 @@ public val TestScope.testTimeSource: TimeSource.WithComparableMarks get() = test
  * Creates a [TestScope].
  *
  * It ensures that all the test module machinery is properly initialized.
- * * If [context] doesn't provide a [TestCoroutineScheduler] for orchestrating the virtual time used for delay-skipping,
+ * - If [context] doesn't provide a [TestCoroutineScheduler] for orchestrating the virtual time used for delay-skipping,
  *   a new one is created, unless either
  *   - a [TestDispatcher] is provided, in which case [TestDispatcher.scheduler] is used;
  *   - at the moment of the creation of the scope, [Dispatchers.Main] is delegated to a [TestDispatcher], in which case
  *     its [TestCoroutineScheduler] is used.
- * * If [context] doesn't have a [TestDispatcher], a [StandardTestDispatcher] is created.
- * * A [CoroutineExceptionHandler] is created that makes [TestCoroutineScope.cleanupTestCoroutines] throw if there were
+ * - If [context] doesn't have a [TestDispatcher], a [StandardTestDispatcher] is created.
+ * - A [CoroutineExceptionHandler] is created that makes [TestCoroutineScope.cleanupTestCoroutines] throw if there were
  *   any uncaught exceptions, or forwards the exceptions further in a platform-specific manner if the cleanup was
  *   already performed when an exception happened. Passing a [CoroutineExceptionHandler] is illegal, unless it's an
  *   [UncaughtExceptionCaptor], in which case the behavior is preserved for the time being for backward compatibility.
  *   If you need to have a specific [CoroutineExceptionHandler], please pass it to [launch] on an already-created
  *   [TestCoroutineScope] and share your use case at
  *   [our issue tracker](https://github.com/Kotlin/kotlinx.coroutines/issues).
- * * If [context] provides a [Job], that job is used as a parent for the new scope.
+ * - If [context] provides a [Job], that job is used as a parent for the new scope.
  *
  * @throws IllegalArgumentException if [context] has both [TestCoroutineScheduler] and a [TestDispatcher] linked to a
  * different scheduler.
diff --git a/kotlinx-coroutines-test/jvm/src/migration/TestCoroutineScope.kt b/kotlinx-coroutines-test/jvm/src/migration/TestCoroutineScope.kt
index f172ab63..d026e32e 100644
--- a/kotlinx-coroutines-test/jvm/src/migration/TestCoroutineScope.kt
+++ b/kotlinx-coroutines-test/jvm/src/migration/TestCoroutineScope.kt
@@ -24,11 +24,11 @@ public interface TestCoroutineScope : CoroutineScope {
     /**
      * Called after the test completes.
      *
-     * * It checks that there were no uncaught exceptions caught by its [CoroutineExceptionHandler].
+     * - It checks that there were no uncaught exceptions caught by its [CoroutineExceptionHandler].
      *   If there were any, then the first one is thrown, whereas the rest are suppressed by it.
-     * * It runs the tasks pending in the scheduler at the current time. If there are any uncompleted tasks afterwards,
+     * - It runs the tasks pending in the scheduler at the current time. If there are any uncompleted tasks afterwards,
      *   it fails with [UncompletedCoroutinesError].
-     * * It checks whether some new child [Job]s were created but not completed since this [TestCoroutineScope] was
+     * - It checks whether some new child [Job]s were created but not completed since this [TestCoroutineScope] was
      *   created. If so, it fails with [UncompletedCoroutinesError].
      *
      * For backward compatibility, if the [CoroutineExceptionHandler] is an [UncaughtExceptionCaptor], its
@@ -151,20 +151,20 @@ public fun TestCoroutineScope(context: CoroutineContext = EmptyCoroutineContext)
  * for an instruction on how to update the code for the new API.
  *
  * It ensures that all the test module machinery is properly initialized.
- * * If [context] doesn't define a [TestCoroutineScheduler] for orchestrating the virtual time used for delay-skipping,
+ * - If [context] doesn't define a [TestCoroutineScheduler] for orchestrating the virtual time used for delay-skipping,
  *   a new one is created, unless either
  *   - a [TestDispatcher] is provided, in which case [TestDispatcher.scheduler] is used;
  *   - at the moment of the creation of the scope, [Dispatchers.Main] is delegated to a [TestDispatcher], in which case
  *     its [TestCoroutineScheduler] is used.
- * * If [context] doesn't have a [ContinuationInterceptor], a [StandardTestDispatcher] is created.
- * * A [CoroutineExceptionHandler] is created that makes [TestCoroutineScope.cleanupTestCoroutines] throw if there were
+ * - If [context] doesn't have a [ContinuationInterceptor], a [StandardTestDispatcher] is created.
+ * - A [CoroutineExceptionHandler] is created that makes [TestCoroutineScope.cleanupTestCoroutines] throw if there were
  *   any uncaught exceptions, or forwards the exceptions further in a platform-specific manner if the cleanup was
  *   already performed when an exception happened. Passing a [CoroutineExceptionHandler] is illegal, unless it's an
  *   [UncaughtExceptionCaptor], in which case the behavior is preserved for the time being for backward compatibility.
  *   If you need to have a specific [CoroutineExceptionHandler], please pass it to [launch] on an already-created
  *   [TestCoroutineScope] and share your use case at
  *   [our issue tracker](https://github.com/Kotlin/kotlinx.coroutines/issues).
- * * If [context] provides a [Job], that job is used for the new scope; otherwise, a [CompletableJob] is created.
+ * - If [context] provides a [Job], that job is used for the new scope; otherwise, a [CompletableJob] is created.
  *
  * @throws IllegalArgumentException if [context] has both [TestCoroutineScheduler] and a [TestDispatcher] linked to a
  * different scheduler.