@@ -292,6 +292,9 @@ Try running `cargo miri clean`.
292292Miri adds its own set of `-Z` flags, which are usually set via the `MIRIFLAGS`
293293environment variable. We first document the most relevant and most commonly used flags :
294294
295+ * `-Zmiri-backtrace=<0|1|full>` configures how Miri prints backtraces: `1` is the default,
296+ where backtraces are printed in pruned form; `full` prints backtraces without pruning, and `0`
297+ disables backtraces entirely.
295298* `-Zmiri-deterministic-concurrency` makes Miri's concurrency-related behavior fully deterministic.
296299 Strictly speaking, Miri is always fully deterministic when isolation is enabled (the default
297300 mode), but this determinism is achieved by using an RNG with a fixed seed. Seemingly harmless
@@ -373,6 +376,12 @@ environment variable. We first document the most relevant and most commonly used
373376 ensure alignment. (The standard library `align_to` method works fine in both modes; under
374377 symbolic alignment it only fills the middle slice when the allocation guarantees sufficient
375378 alignment.)
379+ * `-Zmiri-user-relevant-crates=<crate>,<crate>,...` extends the list of crates that Miri considers
380+ " user-relevant" . This affects the rendering of backtraces (for user-relevant crates, Miri shows
381+ not just the function name but the actual code) and it affects the spans collected for data races
382+ and aliasing violations (where Miri will show the span of the topmost non-`#[track_caller]` frame
383+ in a user-relevant crate). When using `cargo miri`, the crates in the local workspace are always
384+ considered user-relevant.
376385
377386The remaining flags are for advanced use only, and more likely to change or be removed.
378387Some of these are **unsound**, which means they can lead
@@ -474,7 +483,8 @@ to Miri failing to detect cases of undefined behavior in a program.
474483* `-Zmiri-track-alloc-id=<id1>,<id2>,...` shows a backtrace when the given allocations are
475484 being allocated or freed. This helps in debugging memory leaks and
476485 use after free bugs. Specifying this argument multiple times does not overwrite the previous
477- values, instead it appends its values to the list. Listing an id multiple times has no effect.
486+ values, instead it appends its values to the list. Listing an ID multiple times has no effect.
487+ You can also add IDs at runtime using `miri_track_alloc`.
478488* `-Zmiri-track-pointer-tag=<tag1>,<tag2>,...` shows a backtrace when a given pointer tag
479489 is created and when (if ever) it is popped from a borrow stack (which is where the tag becomes invalid
480490 and any future use of it will error). This helps you in finding out why UB is
0 commit comments