Skip to content

Commit e69b987

Browse files
authored
mir: begin documenting user variable debuginfo. (#571)
1 parent 5bd60bc commit e69b987

File tree

1 file changed

+22
-10
lines changed

1 file changed

+22
-10
lines changed

src/mir/index.md

+22-10
Original file line numberDiff line numberDiff line change
@@ -84,11 +84,7 @@ with a bunch of variable declarations. They look like this:
8484

8585
```mir
8686
let mut _0: (); // return place
87-
scope 1 {
88-
let mut _1: std::vec::Vec<i32>; // "vec" in scope 1 at src/main.rs:2:9: 2:16
89-
}
90-
scope 2 {
91-
}
87+
let mut _1: std::vec::Vec<i32>; // in scope 0 at src/main.rs:2:9: 2:16
9288
let mut _2: ();
9389
let mut _3: &mut std::vec::Vec<i32>;
9490
let mut _4: ();
@@ -97,11 +93,27 @@ let mut _5: &mut std::vec::Vec<i32>;
9793
9894
You can see that variables in MIR don't have names, they have indices,
9995
like `_0` or `_1`. We also intermingle the user's variables (e.g.,
100-
`_1`) with temporary values (e.g., `_2` or `_3`). You can tell the
101-
difference between user-defined variables have a comment that gives
102-
you their original name (`// "vec" in scope 1...`). The "scope" blocks
103-
(e.g., `scope 1 { .. }`) describe the lexical structure of the source
104-
program (which names were in scope when).
96+
`_1`) with temporary values (e.g., `_2` or `_3`). You can tell apart
97+
user-defined variables because they have debuginfo associated to them (see below).
98+
99+
**User variable debuginfo.** Below the variable declarations, we find the only
100+
hint that `_1` represents a user variable:
101+
```mir
102+
scope 1 {
103+
debug vec => _1; // in scope 1 at src/main.rs:2:9: 2:16
104+
}
105+
```
106+
Each `debug <Name> => <Place>;` annotation describes a named user variable,
107+
and where (i.e. the place) a debugger can find the data of that variable.
108+
Here the mapping is trivial, but optimizations may complicate the place,
109+
or lead to multiple user variables sharing the same place.
110+
Additionally, closure captures are described using the same system, and so
111+
they're complicated even without optimizations, e.g.: `debug x => (*((*_1).0: &T));`.
112+
113+
The "scope" blocks (e.g., `scope 1 { .. }`) describe the lexical structure of
114+
the source program (which names were in scope when), so any part of the program
115+
annotated with `// in scope 0` would be missing `vec`, if you were stepping
116+
through the code in a debugger, for example.
105117

106118
**Basic blocks.** Reading further, we see our first **basic block** (naturally
107119
it may look slightly different when you view it, and I am ignoring some of the

0 commit comments

Comments
 (0)