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...
2019-11-21 13:52:07 -05:00 · 2019-11-21 13:52:07 -05:00 · d373bca885
parent 55e5a8a2fa
commit d373bca885
5 changed files with 52 additions and 52 deletions
--- a/src/building/how-to-build-and-run.md
+++ b/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
+```
--- a/src/diagnostics.md
+++ b/src/diagnostics.md
@ -291,7 +291,7 @@ Lints can be turned on in groups. These groups are declared in the
 For example,

 ```rust,ignore
-    add_lint_group!(sess,
+add_lint_group!(sess,
    "nonstandard_style",
    NON_CAMEL_CASE_TYPES,
    NON_SNAKE_CASE,
--- a/src/hir.md
+++ b/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
--- a/src/profiling/with_perf.md
+++ b/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
--- a/src/tests/running.md
+++ b/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