update README for some tracing being available on nightlies

Author: RalfJung

README.md

@@ -90,15 +90,15 @@ things (like adding support for a new intrinsic) can be done by working just on
 the miri side.
 
 To prepare, make sure you are using a nightly Rust compiler.  You also need to
-set up a libstd that enables execution with miri:
+set up a libstd that enables execution with Miri:
 
 ```sh
 rustup override set nightly # or the nightly in `rust-version`
 cargo run --bin cargo-miri -- miri setup
 ```
 
 The last command should end in printing the directory where the libstd was
-built.  Set that as your MIRI_SYSROOT environment variable:
+built.  Set that as your `MIRI_SYSROOT` environment variable:
 
 ```sh
 export MIRI_SYSROOT=~/.cache/miri/HOST # or whatever the previous command said
@@ -109,7 +109,7 @@ export MIRI_SYSROOT=~/.cache/miri/HOST # or whatever the previous command said
 Now you can run Miri directly, without going through `cargo miri`:
 
 ```sh
-cargo run tests/run-pass-fullmir/format.rs # or whatever test you like
+cargo run tests/run-pass/format.rs # or whatever test you like
 ```
 
 You can also run the test suite with `cargo test --release`.  `cargo test
@@ -120,14 +120,33 @@ less time.
 
 Now you are set up!  You can write a failing test case, and tweak miri until it
 fails no more.
+You can get a trace of which MIR statements are being executed by setting the
+`MIRI_LOG` environment variable.  For example:
+
+```sh
+MIRI_LOG=info cargo run tests/run-pass/vecs.rs
+```
+
+Setting `MIRI_LOG` like this will configure logging for miri itself as well as
+the `rustc::mir::interpret` and `rustc_mir::interpret` modules in rustc.  You
+can also do more targeted configuration, e.g. to debug the stacked borrows
+implementation:
+```sh
+MIRI_LOG=rustc_mir::interpret=info,miri::stacked_borrows cargo run tests/run-pass/vecs.rs
+```
+
+In addition, you can set `MIRI_BACKTRACE=1` to get a backtrace of where an
+evaluation error was originally created.
+
 
 ### Using a locally built rustc
 
 Since the heart of Miri (the main interpreter engine) lives in rustc, working on
 Miri will often require using a locally built rustc.  The bug you want to fix
 may actually be on the rustc side, or you just need to get more detailed trace
-of the execution -- in both cases, you should develop miri against a rustc you
-compiled yourself, with debug assertions (and hence tracing) enabled.
+of the execution than what is possible with release builds -- in both cases, you
+should develop miri against a rustc you compiled yourself, with debug assertions
+(and hence tracing) enabled.
 
 The setup for a local rustc works as follows:
 ```sh
@@ -149,22 +168,6 @@ rustup override set custom
 With this, you should now have a working development setup!  See
 ["Testing Miri"](#testing-miri) above for how to proceed.
 
-Moreover, you can now run Miri with a trace of all execution steps:
-```sh
-MIRI_LOG=debug cargo run tests/run-pass/vecs.rs
-```
-
-Setting `MIRI_LOG` like this will configure logging for miri itself as well as
-the `rustc::mir::interpret` and `rustc_mir::interpret` modules in rustc.  You
-can also do more targeted configuration, e.g. to debug the stacked borrows
-implementation:
-```sh
-MIRI_LOG=rustc_mir::interpret=debug,miri::stacked_borrows cargo run tests/run-pass/vecs.rs
-```
-
-In addition, you can set `MIRI_BACKTRACE=1` to get a backtrace of where an
-evaluation error was originally created.
-
 ### Miri `-Z` flags and environment variables
 
 Several `-Z` flags are relevant for Miri: