Couple of changes to code so that its safe

Specifically, `> $1` causes it to write into the file $1 if it exist
And `> ./x.py` is particularly bad because it overwrite the script with
empty spaces...

Author: hbina

src/building/how-to-build-and-run.md

@@ -145,7 +145,7 @@ Once you've created a config.toml, you are now ready to run
 probably the best "go to" command for building a local rust:
 
 ```bash
-> ./x.py build -i --stage 1 src/libstd
+./x.py build -i --stage 1 src/libstd
 ```
 
 This may *look* like it only builds libstd, but that is not the case.
@@ -190,19 +190,19 @@ build`) has quite a few more steps:
 Build only the libcore library
 
 ```bash
-> ./x.py build src/libcore
+./x.py build src/libcore
 ```
 
 Build the libcore and libproc_macro library only
 
 ```bash
-> ./x.py build src/libcore src/libproc_macro
+./x.py build src/libcore src/libproc_macro
 ```
 
 Build only libcore up to Stage 1
 
 ```bash
-> ./x.py build src/libcore --stage 1
+./x.py build src/libcore --stage 1
 ```
 
 Sometimes you might just want to test if the part you’re working on can
@@ -221,8 +221,8 @@ you will likely need to build at some point; for example, if you want
 to run the entire test suite).
 
 ```bash
-> rustup toolchain link stage1 build/<host-triple>/stage1
-> rustup toolchain link stage2 build/<host-triple>/stage2
+rustup toolchain link stage1 build/<host-triple>/stage1
+rustup toolchain link stage2 build/<host-triple>/stage2
 ```
 
 The `<host-triple>` would typically be one of the following:
@@ -236,7 +236,7 @@ should see a version number ending in `-dev`, indicating a build from
 your local environment:
 
 ```bash
-> rustc +stage1 -vV
+$ rustc +stage1 -vV
 rustc 1.25.0-dev
 binary: rustc
 commit-hash: unknown
@@ -272,6 +272,6 @@ If you need to run this then rustbuild is most likely not acting right and
 you should file a bug as to what is going wrong. If you do need to clean
 everything up then you only need to run one command!
 
-   ```bash
-   > ./x.py clean
-   ```
+```bash
+./x.py clean
+```

src/diagnostics.md

@@ -291,11 +291,11 @@ Lints can be turned on in groups. These groups are declared in the
 For example,
 
 ```rust,ignore
-    add_lint_group!(sess,
-                    "nonstandard_style",
-                    NON_CAMEL_CASE_TYPES,
-                    NON_SNAKE_CASE,
-                    NON_UPPER_CASE_GLOBALS);
+add_lint_group!(sess,
+    "nonstandard_style",
+    NON_CAMEL_CASE_TYPES,
+    NON_SNAKE_CASE,
+    NON_UPPER_CASE_GLOBALS);
 ```
 
 This defines the `nonstandard_style` group which turns on the listed lints. A

src/hir.md

@@ -15,7 +15,7 @@ You can view the HIR representation of your code by passing the
 `-Zunpretty=hir-tree` flag to rustc:
 
 ```bash
-> cargo rustc -- -Zunpretty=hir-tree
+cargo rustc -- -Zunpretty=hir-tree
 ```
 
 ### Out-of-band storage and the `Crate` type

src/profiling/with_perf.md

@@ -28,7 +28,7 @@ of events, though, like cache misses and so forth.
 The basic `perf` command is this:
 
 ```bash
-> perf record -F99 --call-graph dwarf XXX
+perf record -F99 --call-graph dwarf XXX
 ```
 
 The `-F99` tells perf to sample at 99 Hz, which avoids generating too
@@ -39,7 +39,7 @@ information from debuginfo, which is accurate. The `XXX` is the
 command you want to profile. So, for example, you might do:
 
 ```bash
-> perf record -F99 --call-graph dwarf cargo +<toolchain> rustc
+perf record -F99 --call-graph dwarf cargo +<toolchain> rustc
 ```
 
 to run `cargo` -- here `<toolchain>` should be the name of the toolchain
@@ -59,7 +59,7 @@ do that, the first step is to clone
 [the rustc-perf repository][rustc-perf-gh]:
 
 ```bash
-> git clone https://github.com/rust-lang-nursery/rustc-perf
+git clone https://github.com/rust-lang-nursery/rustc-perf
 ```
 
 [rustc-perf-gh]: https://github.com/rust-lang-nursery/rustc-perf
@@ -75,13 +75,13 @@ do profiling for you! You can find
 For example, to measure the clap-rs test, you might do:
 
 ```bash
-> ./target/release/collector
-    --output-repo /path/to/place/output
-    profile perf-record
-    --rustc /path/to/rustc/executable/from/your/build/directory
-    --cargo `which cargo`
-    --filter clap-rs
-    --builds Check
+./target/release/collector                                      \
+  --output-repo /path/to/place/output                           \
+  profile perf-record                                           \
+  --rustc /path/to/rustc/executable/from/your/build/directory   \
+  --cargo `which cargo`                                         \
+  --filter clap-rs                                              \
+  --builds Check                                                \
 ```
 
 You can also use that same command to use cachegrind or other profiling tools.
@@ -97,7 +97,7 @@ example:
 [dir]: https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks
 
 ```bash
-> cd collector/benchmarks/clap-rs
+cd collector/benchmarks/clap-rs
 ```
 
 In this case, let's say we want to profile the `cargo check`
@@ -106,8 +106,8 @@ build the dependencies:
 
 ```bash
 # Setup: first clean out any old results and build the dependencies:
-> cargo +<toolchain> clean
-> CARGO_INCREMENTAL=0 cargo +<toolchain> check
+cargo +<toolchain> clean
+CARGO_INCREMENTAL=0 cargo +<toolchain> check
 ```
 
 (Again, `<toolchain>` should be replaced with the name of the
@@ -118,8 +118,8 @@ running cargo check. I tend to use `cargo rustc` for this, since it
 also allows me to add explicit flags, which we'll do later on.
 
 ```bash
-> touch src/lib.rs
-> CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib
+touch src/lib.rs
+CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib
 ```
 
 Note that final command: it's a doozy! It uses the `cargo rustc`
@@ -130,7 +130,7 @@ the `--profile check` and `--lib` options specify that we are doing a
 At this point, we can use `perf` tooling to analyze the results. For example:
 
 ```bash
-> perf report
+perf report
 ```
 
 will open up an interactive TUI program. In simple cases, that can be
@@ -149,8 +149,8 @@ If you want to profile an NLL run, you can just pass extra options to
 the `cargo rustc` command, like so:
 
 ```bash
-> touch src/lib.rs
-> CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Zborrowck=mir
+touch src/lib.rs
+CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Zborrowck=mir
 ```
 
 [pf]: https://github.com/nikomatsakis/perf-focus
@@ -180,7 +180,7 @@ would analyze NLL performance.
 You can install perf-focus using `cargo install`:
 
 ```bash
-> cargo install perf-focus
+cargo install perf-focus
 ```
 
 ### Example: How much time is spent in MIR borrowck?
@@ -191,7 +191,7 @@ function of the MIR borrowck is called `do_mir_borrowck`, so we can do
 this command:
 
 ```bash
-> perf focus '{do_mir_borrowck}'
+$ perf focus '{do_mir_borrowck}'
 Matcher    : {do_mir_borrowck}
 Matches    : 228
 Not Matches: 542
@@ -216,7 +216,7 @@ samples where `do_mir_borrowck` was on the stack: in this case, 29%.
   by doing:
 
 ```bash
-> perf script | c++filt | perf focus --from-stdin ...
+perf script | c++filt | perf focus --from-stdin ...
 ```
 
 This will pipe the output from `perf script` through `c++filt` and
@@ -232,7 +232,7 @@ Perhaps we'd like to know how much time MIR borrowck spends in the
 trait checker. We can ask this using a more complex regex:
 
 ```bash
-> perf focus '{do_mir_borrowck}..{^rustc::traits}'
+$ perf focus '{do_mir_borrowck}..{^rustc::traits}'
 Matcher    : {do_mir_borrowck},..{^rustc::traits}
 Matches    : 12
 Not Matches: 1311
@@ -260,7 +260,7 @@ usually also want to give `--tree-min-percent` or
 `--tree-max-depth`. The result looks like this:
 
 ```bash
-> perf focus '{do_mir_borrowck}' --tree-callees --tree-min-percent 3
+$ perf focus '{do_mir_borrowck}' --tree-callees --tree-min-percent 3
 Matcher    : {do_mir_borrowck}
 Matches    : 577
 Not Matches: 746
@@ -311,7 +311,7 @@ could get our percentages relative to the borrowck itself
 like so:
 
 ```bash
-> perf focus '{do_mir_borrowck}' --tree-callees --relative --tree-max-depth 1 --tree-min-percent 5
+$ perf focus '{do_mir_borrowck}' --tree-callees --relative --tree-max-depth 1 --tree-min-percent 5
 Matcher    : {do_mir_borrowck}
 Matches    : 577
 Not Matches: 746

src/tests/running.md

@@ -4,7 +4,7 @@ You can run the tests using `x.py`. The most basic command – which
 you will almost never want to use! – is as follows:
 
 ```bash
-> ./x.py test
+./x.py test
 ```
 
 This will build the full stage 2 compiler and then run the whole test
@@ -34,7 +34,7 @@ test" that can be used after modifying rustc to see if things are
 generally working correctly would be the following:
 
 ```bash
-> ./x.py test --stage 1 src/test/{ui,compile-fail}
+./x.py test --stage 1 src/test/{ui,compile-fail}
 ```
 
 This will run the `ui` and `compile-fail` test suites,
@@ -44,38 +44,38 @@ example, if you are hacking on debuginfo, you may be better off with
 the debuginfo test suite:
 
 ```bash
-> ./x.py test --stage 1 src/test/debuginfo
+./x.py test --stage 1 src/test/debuginfo
 ```
 
 If you only need to test a specific subdirectory of tests for any
 given test suite, you can pass that directory to `x.py test`:
 
 ```bash
-> ./x.py test --stage 1 src/test/ui/const-generics
+./x.py test --stage 1 src/test/ui/const-generics
 ```
 
 Likewise, you can test a single file by passing its path:
 
 ```bash
-> ./x.py test --stage 1 src/test/ui/const-generics/const-test.rs
+./x.py test --stage 1 src/test/ui/const-generics/const-test.rs
 ```
 
 ### Run only the tidy script
 
 ```bash
-> ./x.py test src/tools/tidy
+./x.py test src/tools/tidy
 ```
 
 ### Run tests on the standard library
 
 ```bash
-> ./x.py test src/libstd
+./x.py test src/libstd
 ```
 
 ### Run tests on the standard library and run the tidy script
 
 ```bash
-> ./x.py test src/libstd src/tools/tidy
+./x.py test src/libstd src/tools/tidy
 ```
 
 ### Run tests on the standard library using a stage 1 compiler
@@ -100,7 +100,7 @@ you may pass the full file path to achieve this, or alternatively one
 may invoke `x.py` with the `--test-args` option:
 
 ```bash
-> ./x.py test --stage 1 src/test/ui --test-args issue-1234
+./x.py test --stage 1 src/test/ui --test-args issue-1234
 ```
 
 Under the hood, the test runner invokes the standard rust test runner
@@ -117,7 +117,7 @@ exists in the test file. For example, you can run all the tests in
 `src/test/ui` as `check-pass`:
 
 ```bash
-> ./x.py test --stage 1 src/test/ui --pass check
+./x.py test --stage 1 src/test/ui --pass check
 ```
 
 By passing `--pass $mode`, you can reduce the testing time. For each
@@ -131,7 +131,7 @@ You can further enable the `--incremental` flag to save additional
 time in subsequent rebuilds:
 
 ```bash
-> ./x.py test --stage 1 src/test/ui --incremental --test-args issue-1234
+./x.py test --stage 1 src/test/ui --incremental --test-args issue-1234
 ```
 
 If you don't want to include the flag with every command, you can
@@ -152,7 +152,7 @@ Sometimes it's easier and faster to just run the test by hand. Most tests are
 just `rs` files, so you can do something like
 
 ```bash
-> rustc +stage1 src/test/ui/issue-1234.rs
+rustc +stage1 src/test/ui/issue-1234.rs
 ```
 
 This is much faster, but doesn't always work. For example, some tests