X-Git-Url: https://git.lizzy.rs/?a=blobdiff_plain;f=CONTRIBUTING.md;h=42f77b5cbc0ed54667481ef12503134f62b2e33d;hb=d2ba40e9e1ff18f14b2d75462c0f7d7afcae7e76;hp=b74444fbc6e4e6a8e6585917e051417fefaa25e2;hpb=0a4279fed9cc91e4e8921fff3b27d1c152f13b07;p=rust.git

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b74444fbc6e..42f77b5cbc0 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -28,6 +28,11 @@ install that exact version of rustc as a toolchain:
 This will set up a rustup toolchain called `miri` and set it as an override for
 the current directory.
 
+You can also create a `.auto-everything` file (contents don't matter, can be empty), which
+will cause any `./miri` command to automatically call `rustup-toolchain`, `clippy` and `rustfmt`
+for you. If you don't want all of these to happen, you can add individual `.auto-toolchain`,
+`.auto-clippy` and `.auto-fmt` files respectively.
+
 [`rustup-toolchain-install-master`]: https://github.com/kennytm/rustup-toolchain-install-master
 
 ## Building and testing Miri
@@ -55,8 +60,8 @@ generation and linking obviously will have no effect) [and more][miri-flags].
 For example, you can (cross-)run the driver on a particular file by doing
 
 ```sh
-./miri run tests/run-pass/format.rs
-./miri run tests/run-pass/hello.rs --target i686-unknown-linux-gnu
+./miri run tests/pass/format.rs
+./miri run tests/pass/hello.rs --target i686-unknown-linux-gnu
 ```
 
 and you can (cross-)run the entire test suite using:
@@ -66,6 +71,16 @@ and you can (cross-)run the entire test suite using:
 MIRI_TEST_TARGET=i686-unknown-linux-gnu ./miri test
 ```
 
+If your target doesn't support libstd, you can run miri with
+
+```
+MIRI_NO_STD=1 MIRI_TEST_TARGET=thumbv7em-none-eabihf ./miri test tests/fail/alloc/no_global_allocator.rs
+MIRI_NO_STD=1 ./miri run tests/pass/no_std.rs --target thumbv7em-none-eabihf
+```
+
+to avoid attempting (and failing) to build libstd. Note that almost no tests will pass
+this way, but you can run individual tests.
+
 `./miri test FILTER` only runs those tests that contain `FILTER` in their
 filename (including the base directory, e.g. `./miri test fail` will run all
 compile-fail tests).
@@ -74,7 +89,7 @@ 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 ./miri run tests/run-pass/vec.rs
+MIRI_LOG=info ./miri run tests/pass/vec.rs
 ```
 
 Setting `MIRI_LOG` like this will configure logging for Miri itself as well as
@@ -83,7 +98,7 @@ can also do more targeted configuration, e.g. the following helps debug the
 stacked borrows implementation:
 
 ```sh
-MIRI_LOG=rustc_mir::interpret=info,miri::stacked_borrows ./miri run tests/run-pass/vec.rs
+MIRI_LOG=rustc_mir::interpret=info,miri::stacked_borrows ./miri run tests/pass/vec.rs
 ```
 
 In addition, you can set `MIRI_BACKTRACE=1` to get a backtrace of where an
@@ -116,6 +131,8 @@ development version of Miri using
 
 and then you can use it as if it was installed by `rustup`.  Make sure you use
 the same toolchain when calling `cargo miri` that you used when installing Miri!
+Usually this means you have to write `cargo +miri miri ...` to select the `miri`
+toolchain that was installed by `./rustup-toolchain`.
 
 There's a test for the cargo wrapper in the `test-cargo-miri` directory; run
 `./run-test.py` in there to execute it. Like `./miri test`, this respects the
@@ -129,7 +146,14 @@ build Miri yourself, the Miri shipped by `rustup` will work. All you have to do
 is set the `MIRI_LIB_SRC` environment variable to the `library` folder of a
 `rust-lang/rust` repository checkout. Note that changing files in that directory
 does not automatically trigger a re-build of the standard library; you have to
-clear the Miri build cache manually (on Linux, `rm -rf ~/.cache/miri`).
+clear the Miri build cache manually (on Linux, `rm -rf ~/.cache/miri`;
+and on Windows, `rmdir /S "%LOCALAPPDATA%\rust-lang\miri\cache"`).
+
+### Benchmarking
+
+Miri comes with a few benchmarks; you can run `./miri bench` to run them with the locally built
+Miri. Note: this will run `./miri install` as a side-effect. Also requires `hyperfine` to be
+installed (`cargo install hyperfine`).
 
 ## Configuring `rust-analyzer`
 
@@ -138,19 +162,28 @@ to `.vscode/settings.json` in your local Miri clone:
 
 ```json
 {
+    "rust-analyzer.rustc.source": "discover",
+    "rust-analyzer.linkedProjects": [
+        "./Cargo.toml",
+        "./cargo-miri/Cargo.toml"
+    ],
     "rust-analyzer.checkOnSave.overrideCommand": [
+        "env",
+        "MIRI_AUTO_OPS=no",
         "./miri",
         "check",
         "--message-format=json"
     ],
+    "rust-analyzer.buildScripts.overrideCommand": [
+        "env",
+        "MIRI_AUTO_OPS=no",
+        "./miri",
+        "check",
+        "--message-format=json",
+    ],
     "rust-analyzer.rustfmt.extraArgs": [
         "+nightly"
     ],
-    "rust-analyzer.rustcSource": "discover",
-    "rust-analyzer.linkedProjects": [
-        "./Cargo.toml",
-        "./cargo-miri/Cargo.toml"
-    ]
 }
 ```
 
@@ -220,8 +253,17 @@ rustup toolchain link stage2 build/x86_64-unknown-linux-gnu/stage2
 rustup override set stage2
 ```
 
+Note: When you are working with a locally built rustc or any other toolchain that
+is not the same as the one in `rust-version`, you should not have `.auto-everything` or
+`.auto-toolchain` as that will keep resetting your toolchain.
+
+```
+rm -f .auto-everything .auto-toolchain
+```
+
 Important: You need to delete the Miri cache when you change the stdlib; otherwise the
-old, chached version will be used. On Linux, the cache is located at `~/.cache/miri`; the exact
+old, chached version will be used. On Linux, the cache is located at `~/.cache/miri`,
+and on Windows, it is located at `%LOCALAPPDATA%\rust-lang\miri\cache`; the exact
 location is printed after the library build: "A libstd for Miri is now available in ...".
 
 Note: `./x.py --stage 2 compiler/rustc` currently errors with `thread 'main'