diff --git a/src/borrow_check/two_phase_borrows.md b/src/borrow_check/two_phase_borrows.md
index b77ae0946..d38724335 100644
--- a/src/borrow_check/two_phase_borrows.md
+++ b/src/borrow_check/two_phase_borrows.md
@@ -15,7 +15,7 @@ two-phase borrow are:
 
 To give some examples:
 
-```rust2018
+```rust,edition2018
 // In the source code
 
 // Case 1:
diff --git a/src/coroutine-closures.md b/src/coroutine-closures.md
index 2617c824a..45d6a24a6 100644
--- a/src/coroutine-closures.md
+++ b/src/coroutine-closures.md
@@ -167,7 +167,7 @@ We introduce a `AsyncFnKindHelper` trait which allows us to defer the question o
 
 This seems a bit roundabout and complex, and I admit that it is. But let's think of the "do nothing" alternative -- we could instead mark all `AsyncFn*` goals as ambiguous until upvar analysis, at which point we would know exactly what to put into the upvars of the coroutine we return. However, this is actually *very* detrimental to inference in the program, since it means that programs like this would not be valid:
 
-```rust!
+```rust,ignore
 let c = async || -> String { .. };
 let s = c().await;
 // ^^^ If we can't project `<{c} as AsyncFn>::call()` to a coroutine, then the `IntoFuture::into_future` call inside of the `.await` stalls, and the type of `s` is left unconstrained as an infer var.
diff --git a/src/offload/usage.md b/src/offload/usage.md
index 7d1a5c9e2..9d5839334 100644
--- a/src/offload/usage.md
+++ b/src/offload/usage.md
@@ -79,7 +79,7 @@ Now we generate the device code. Replace the target-cpu with the right code for
 RUSTFLAGS="-Ctarget-cpu=gfx90a --emit=llvm-bc,llvm-ir" cargo +offload build -Zunstable-options -r -v --target amdgcn-amd-amdhsa -Zbuild-std=core
 ```
 
-Now find the <libname>.ll under target/amdgcn-amd-amdhsa folder and copy it to a device.ll file (or adjust the file names below).
+Now find the `<libname>.ll` under target/amdgcn-amd-amdhsa folder and copy it to a device.ll file (or adjust the file names below).
 If you work on an NVIDIA or Intel gpu, please adjust the names acordingly and open an issue to share your results (either if you succeed or fail).
 First we compile our .ll files (good for manual inspections) to .bc files and clean up leftover artifacts. The cleanup is important, otherwise caching might interfere on following runs.
 ```