@@ -71,19 +71,12 @@ and you can (cross-)run the entire test suite using:
71
71
MIRI_TEST_TARGET=i686-unknown-linux-gnu ./miri test
72
72
```
73
73
74
- If your target doesn't support libstd, you can run miri with
74
+ If your target doesn't support libstd that should usually just work. However, if you are using a
75
+ custom target file, you might have to set ` MIRI_NO_STD=1 ` .
75
76
76
- ```
77
- MIRI_NO_STD=1 MIRI_TEST_TARGET=thumbv7em-none-eabihf ./miri test tests/fail/alloc/no_global_allocator.rs
78
- MIRI_NO_STD=1 ./miri run tests/pass/no_std.rs --target thumbv7em-none-eabihf
79
- ```
80
-
81
- to avoid attempting (and failing) to build libstd. Note that almost no tests will pass
82
- this way, but you can run individual tests.
83
-
84
- ` ./miri test FILTER ` only runs those tests that contain ` FILTER ` in their
85
- filename (including the base directory, e.g. ` ./miri test fail ` will run all
86
- compile-fail tests).
77
+ ` ./miri test FILTER ` only runs those tests that contain ` FILTER ` in their filename (including the
78
+ base directory, e.g. ` ./miri test fail ` will run all compile-fail tests). These filters are passed
79
+ to ` cargo test ` , so for multiple filers you need to use ` ./miri test -- FILTER1 FILTER2 ` .
87
80
88
81
You can get a trace of which MIR statements are being executed by setting the
89
82
` MIRI_LOG ` environment variable. For example:
@@ -107,7 +100,7 @@ evaluation error was originally raised.
107
100
### UI testing
108
101
109
102
We use ui-testing in Miri, meaning we generate ` .stderr ` and ` .stdout ` files for the output
110
- produced by Miri. You can use ` ./miri bless ` to automatically (re)generate these files when
103
+ produced by Miri. You can use ` ./miri test -- bless ` to automatically (re)generate these files when
111
104
you add new tests or change how Miri presents certain output.
112
105
113
106
Note that when you also use ` MIRIFLAGS ` to change optimizations and similar, the ui output
@@ -116,7 +109,7 @@ to run the other checks while ignoring the ui output, use `MIRI_SKIP_UI_CHECKS=1
116
109
117
110
For more info on how to configure ui tests see [ the documentation on the ui test crate] [ ui_test ]
118
111
119
- [ ui_test ] : ui_test/README.md
112
+ [ ui_test ] : https://github.com/oli-obk/ ui_test/blob/main /README.md
120
113
121
114
### Testing ` cargo miri `
122
115
@@ -129,18 +122,15 @@ development version of Miri using
129
122
./miri install
130
123
```
131
124
132
- and then you can use it as if it was installed by ` rustup ` . Make sure you use
133
- the same toolchain when calling ` cargo miri` that you used when installing Miri!
134
- Usually this means you have to write ` cargo +miri miri ... ` to select the ` miri `
135
- toolchain that was installed by ` ./miri toolchain ` .
125
+ and then you can use it as if it was installed by ` rustup ` as a component of the
126
+ ` miri ` toolchain. Note that the ` miri ` and ` cargo-miri ` executables are placed
127
+ in the ` miri ` toolchain's sysroot to prevent conflicts with other toolchains.
128
+ The Miri binaries in the ` cargo ` bin directory (usually ` ~/.cargo/bin ` ) are managed by rustup .
136
129
137
130
There's a test for the cargo wrapper in the ` test-cargo-miri ` directory; run
138
131
` ./run-test.py ` in there to execute it. Like ` ./miri test ` , this respects the
139
132
` MIRI_TEST_TARGET ` environment variable to execute the test for another target.
140
133
141
- Note that installing Miri like this will "take away" Miri management from ` rustup ` .
142
- If you want to later go back to a rustup-installed Miri, run ` rustup update ` .
143
-
144
134
### Using a modified standard library
145
135
146
136
Miri re-builds the standard library into a custom sysroot, so it is fairly easy
@@ -168,16 +158,17 @@ to `.vscode/settings.json` in your local Miri clone:
168
158
{
169
159
"rust-analyzer.rustc.source" : " discover" ,
170
160
"rust-analyzer.linkedProjects" : [
171
- " ./Cargo.toml" ,
172
- " ./cargo-miri/Cargo.toml"
161
+ " Cargo.toml" ,
162
+ " cargo-miri/Cargo.toml" ,
163
+ " miri-script/Cargo.toml" ,
173
164
],
174
- "rust-analyzer.checkOnSave .overrideCommand" : [
165
+ "rust-analyzer.check .overrideCommand" : [
175
166
" env" ,
176
167
" MIRI_AUTO_OPS=no" ,
177
168
" ./miri" ,
178
169
" cargo" ,
179
170
" clippy" , // make this `check` when working with a locally built rustc
180
- " --message-format=json"
171
+ " --message-format=json" ,
181
172
],
182
173
// Contrary to what the name suggests, this also affects proc macros.
183
174
"rust-analyzer.cargo.buildScripts.overrideCommand" : [
@@ -232,19 +223,17 @@ You can also directly run Miri on a Rust source file:
232
223
233
224
## Advanced topic: Syncing with the rustc repo
234
225
235
- We use the [ ` josh ` proxy] ( https://github.com/josh-project/josh ) to transmit
236
- changes between the rustc and Miri repositories. For now, the latest git version
237
- of josh needs to be built from source. This downloads and runs josh:
226
+ We use the [ ` josh ` proxy] ( https://github.com/josh-project/josh ) to transmit changes between the
227
+ rustc and Miri repositories. You can install it as follows:
238
228
239
229
``` sh
240
- git clone https://github.com/josh-project/josh
241
- cd josh
242
- cargo run --release -p josh-proxy -- --local=local --remote=https://github.com --no-background
230
+ cargo +stable install josh-proxy --git https://github.com/josh-project/josh --tag r22.12.06
243
231
```
244
232
233
+ Josh will automatically be started and stopped by ` ./miri ` .
234
+
245
235
### Importing changes from the rustc repo
246
236
247
- Josh needs to be running, as described above.
248
237
We assume we start on an up-to-date master branch in the Miri repo.
249
238
250
239
``` sh
@@ -263,16 +252,14 @@ needed.
263
252
264
253
### Exporting changes to the rustc repo
265
254
266
- Keep in mind that pushing is the most complicated job that josh has to do --
267
- pulling just filters the rustc history, but pushing needs to construct a new
268
- rustc history that would filter to the given Miri history! To avoid problems, it
269
- is a good idea to always pull immediately before you push. In particular, you
270
- should never do two josh pushes without an intermediate pull; that can lead to
271
- duplicated commits.
255
+ Keep in mind that pushing is the most complicated job that josh has to do -- pulling just filters
256
+ the rustc history, but pushing needs to construct a new rustc history that would filter to the given
257
+ Miri history! To avoid problems, it is a good idea to always pull immediately before you push. If
258
+ you are getting strange errors, chances are you are running into [ this josh
259
+ bug] ( https://github.com/josh-project/josh/issues/998 ) . In that case, please get in touch on Zulip.
272
260
273
- Josh needs to be running, as described above. We will use the josh proxy to push
274
- to your fork of rustc. Run the following in the Miri repo, assuming we are on an
275
- up-to-date master branch:
261
+ We will use the josh proxy to push to your fork of rustc. Run the following in the Miri repo,
262
+ assuming we are on an up-to-date master branch:
276
263
277
264
``` sh
278
265
# Push the Miri changes to your rustc fork (substitute your github handle for YOUR_NAME).
@@ -282,3 +269,11 @@ up-to-date master branch:
282
269
This will create a new branch called 'miri' in your fork, and the output should
283
270
include a link to create a rustc PR that will integrate those changes into the
284
271
main repository.
272
+
273
+ If this fails due to authentication problems, it can help to make josh push via ssh instead of
274
+ https. Add the following to your ` .gitconfig ` :
275
+
276
+ ``` toml
277
+ [url "git@github .com:" ]
278
+ pushInsteadOf = https://github.com/
279
+ ```
0 commit comments