second level header - remove code

Author: Quattro8

docs/topics/cancellation-and-timeouts.md

@@ -189,7 +189,7 @@ main: I'm tired of waiting!
 main: Now I can quit.
 -->
 
-## Closing resources with `finally`
+## Closing resources with finally
 
 Cancellable suspending functions throw [CancellationException] on cancellation, which can be handled in 
 the usual way. For example, the `try {...} finally {...}` expression and Kotlin's `use` function execute their

kotlinx-coroutines-test/MIGRATION.md

@@ -4,7 +4,7 @@ In version 1.6.0, the API of the test module changed significantly.
 This is a guide for gradually adapting the existing test code to the new API.
 This guide is written step-by-step; the idea is to separate the migration into several sets of small changes.
 
-## Remove custom `UncaughtExceptionCaptor`, `DelayController`, and `TestCoroutineScope` implementations
+## Remove custom UncaughtExceptionCaptor, DelayController, and TestCoroutineScope implementations
 
 We couldn't find any code that defined new implementations of these interfaces, so they are deprecated. It's likely that
 you don't need to do anything for this section.
@@ -61,7 +61,7 @@ So, there could be two reasons for defining a custom implementation:
 * Using without `runBlockingTest`. In this case, you don't even need to implement `TestCoroutineScope`: nothing else
   accepts a `TestCoroutineScope` specifically as an argument.
 
-## Remove usages of `TestCoroutineExceptionHandler` and `TestCoroutineScope.uncaughtExceptions`
+## Remove usages of TestCoroutineExceptionHandler and TestCoroutineScope.uncaughtExceptions
 
 It is already illegal to use a `TestCoroutineScope` without performing `cleanupTestCoroutines`, so the valid uses of
 `TestCoroutineExceptionHandler` include:
@@ -93,13 +93,13 @@ fun testFoo() = runTest {
 }
 ```
 
-## Auto-replace `TestCoroutineScope` constructor function with `createTestCoroutineScope`
+## Auto-replace TestCoroutineScope constructor function with createTestCoroutineScope
 
 This should not break anything, as `TestCoroutineScope` is now defined in terms of `createTestCoroutineScope`.
 If it does break something, it means that you already supplied a `TestCoroutineScheduler` to some scope; in this case,
 also pass this scheduler as the argument to the dispatcher.
 
-## Replace usages of `pauseDispatcher` and `resumeDispatcher` with a `StandardTestDispatcher`
+## Replace usages of pauseDispatcher and resumeDispatcher with a StandardTestDispatcher
 
 * In places where `pauseDispatcher` in its block form is called, replace it with a call to
   `withContext(StandardTestDispatcher(testScheduler))`
@@ -120,7 +120,7 @@ also pass this scheduler as the argument to the dispatcher.
   `StandardTestDispatcher` (where dispatches are needed) and `UnconfinedTestDispatcher` (where it isn't important where
   execution happens).
 
-## Replace `advanceTimeBy(n)` with `advanceTimeBy(n); runCurrent()`
+## Replace advanceTimeBy(n) with advanceTimeBy(n); runCurrent()
 
 For `TestCoroutineScope` and `DelayController`, the `advanceTimeBy` method is deprecated.
 It is not deprecated for `TestCoroutineScheduler` and `TestScope`, but has a different meaning: it does not run the
@@ -131,7 +131,7 @@ There is an automatic replacement for this deprecation, which produces correct b
 Alternatively, you can wait until replacing `TestCoroutineScope` with `TestScope`: it's possible that you will not
 encounter this edge case.
 
-## Replace `runBlockingTest` with `runTest(UnconfinedTestDispatcher())`
+## Replace runBlockingTest with runTest(UnconfinedTestDispatcher())
 
 This is a major change, affecting many things, and can be done in parallel with replacing `TestCoroutineScope` with
 `TestScope`.
@@ -329,7 +329,7 @@ There is a `runTestWithLegacyScope` method that allows migrating from `runBlocki
 from `TestCoroutineScope` to `TestScope`, if exactly the `TestCoroutineScope` needs to be passed somewhere else and
 `TestScope` will not suffice.
 
-## Replace `TestCoroutineScope.cleanupTestCoroutines` with `runTest`
+## Replace TestCoroutineScope.cleanupTestCoroutines with runTest
 
 Likely can be done together with the next step.
 
@@ -363,7 +363,7 @@ fun runTestAndCleanup(body: TestScope.() -> Unit) = runTest {
 }
 ```
 
-## Replace `runBlockingTest` with `runBlockingTestOnTestScope`, `createTestCoroutineScope` with `TestScope`
+## Replace runBlockingTest with runBlockingTestOnTestScope, createTestCoroutineScope with TestScope
 
 Also, replace `runTestWithLegacyScope` with just `runTest`.
 All of this can be done in parallel with replacing `runBlockingTest` with `runTest`.
@@ -379,13 +379,13 @@ handle cancelled tasks differently: if there are *cancelled* jobs pending at the
 Of all the methods supported by `TestCoroutineScope`, only `cleanupTestCoroutines` is not provided on `TestScope`,
 and its usages should have been removed during the previous step.
 
-## Replace `runBlocking` with `runTest`
+## Replace runBlocking with runTest
 
 Now that `runTest` works properly with asynchronous completions, `runBlocking` is only occasionally useful.
 As is, most uses of `runBlocking` in tests come from the need to interact with dispatchers that execute on other
 threads, like `Dispatchers.IO` or `Dispatchers.Default`.
 
-## Replace `TestCoroutineDispatcher` with `UnconfinedTestDispatcher` and `StandardTestDispatcher`
+## Replace TestCoroutineDispatcher with UnconfinedTestDispatcher and StandardTestDispatcher
 
 `TestCoroutineDispatcher` is a dispatcher with two modes:
 * ("unpaused") Almost (but not quite) unconfined, with the ability to eagerly enter `launch` and `async` blocks.

kotlinx-coroutines-test/README.md

@@ -159,7 +159,7 @@ suspend fun foo() {
 }
 ```
 
-## `launch` and `async`
+## launch and async
 
 The coroutine dispatcher used for tests is single-threaded, meaning that the child coroutines of the [runTest] block
 will run on the thread that started the test, and will never run in parallel.
@@ -323,7 +323,7 @@ fun testExampleBackgroundJob() = runTest {
 }
 ```
 
-## Eagerly entering `launch` and `async` blocks
+## Eagerly entering launch and async blocks
 
 Some tests only test functionality and don't particularly care about the precise order in which coroutines are
 dispatched.