I am debugging Rust in VSCode using LLDB. Why do some of the local variables that appear in the debugger disappear when I place a breakpoint at the end of the scope in the image code? Is there a setting to prevent them from disappearing?
Placing a breakpoint at the end of scope to check the value of a local variable is the easiest way to check the value, so we do not want to do the time-consuming method of println debugging, if possible.
The debug information for a variable consists of a series of pc ranges in the program where that variable is visible, and the location in memory or in registers of the variable in each range. Outside of those ranges, the value of the variable is not known. This is a determination made by the compiler, the debugger is just showing you what it wrote in the debug info.
Note, the debug information is capable of expressing that a variable was in a register for some range of pc's, then got moved to the stack for another range, then back to a register, etc. So if the compiler is emitting the debug information correctly, movements like that can be tracked by the debugger.
I don't know why the Rust compiler thinks that at the end of that function `a` is still in scope but `b` is not. However, there's no guarantee in most languages that the storage for a variable be retained throughout the semantic scope of the variable's definition, and languages that manage object lifecycles with ARC or other techniques generally like to get rid of variables after the last bit of code that references them since that makes them more memory efficient. So in general, you're only guaranteed to be able to view a variable before its last use.
Most C compilers when run at -O0 will not reuse stack space for variables in this way. But in swift, for instance, the compiler added a "shadow variable" that is only emitted when the optimizer is off and debug info is being generated that is used to artificially prolong the life of variables to match their scope as an aid in debugging. That was the cleanest way of working around the eagerness of the swift variable reclamation. Maybe Rust needs something like that?
Anyway, the TL;DR is that this is something that will have to be fixed in the Rust compiler. The compiler told us it doesn't know where b is at your current PC, and the debugger should never try to guess about values, that ends up causing more harm than good.
