debug runs outdated build, cant change locals, vsCode

[novel roost]

hello i come from C# / C++. im trying to learn / setup rust but i ran into a problem whilst trying to debug.

If i press "run" everything works as expected, but if i change something in my code and then press debug; it just runs the older build (the one that "run" compiled) and ignore my code changes.

Also if i hit a breakpoint and change a variables value via the locals panel, it just disregards that and keeps using the old value defined in the code.

I was watching some rust tutorials and heard pretty much everything is immutable by default so i also tried changing my variable to mut to see if thatd allow me to change the value via the locals panel; but it didn't.

(im using rust-analyzer and CodeLLDB btw)

thanks.

[quick robin]

Did you save your files?

[novel roost]

thank you 🙏 i didn't realize you had to save manually (i thought itd autosave when you run it like visual studio community does).

i still cant seem to edit the locals after hitting a breakpoint though, it still just uses the var values in the code :/

[iron birch]

can you show the code of the function that you're editing locals in?

I'd expect that the function got compiled in a way which presumes the variable doesn't change, given Rust's strong immutability/single-mutability guarantees, but that's just a hypothesis.

[novel roost]

sorry for the slow reply 😅 , timezones and all that.

but its very simple code as you can see:

fn main() {
    let mut inte: i32 = 44;
    println!("integer value {}", inte);
    println!("integer value {}", inte);
}```

[iron birch]

hm, it doesn't seem like that's the case studying the assembly with or without optimization.

wait, no, I spoke too soon

https://rust.godbolt.org/z/G9Gvb6YMx

if you take a look carefully, the 44 is being stored into the stack at [rsp + 36] and then … wait no I misread again

okay, I cannot give you an "it is compiled like this and therefore…"

but, in general, you should expect that modifying data with a debugger will not necessarily do anything sensible

Rust is built on the principle of immutability-or-single-ownership

The code generated assumes that

When you edit memory with a debugger, you're mutating values that are expected not to be mutated, which is formally "undefined behavior"

Therefore, anything, including nothing, could happen.

[novel roost]

i see. im not arguing btw, so sorry if it sounds like i am, i just want to genuinely know. but if rust is designed like that why does the dedicated rust IDE rust-rover also have that functionality? also how come it refuses to do that despite the variable being declared as mutable?

oh and thank you for taking the time to look into the assembly

[iron birch]

why does the dedicated rust IDE rust-rover also have that functionality?
probably:

1. they reused a debugger that is not built specifically for Rust
2. sometimes modifying memory is worth trying anyway

also how come it refuses to do that despite the variable being declared as mutable?
mutability is always exclusive. the debugger has not been given exclusive access to the data, therefore its writes are not valid within the model

[novel roost]

thank you for the help / explanations. 😁

[iron birch]

if there was a way to write this program:

fn main() {
    let mut inte: i32 = 44;
    println!("integer value {}", inte);
    break_into_debugger_with(&mut inte);
    println!("integer value {}", inte);
}

then that would be 100% fine to do, because you've explicitly handed over a pointer to the mutable data

[novel roost]

gotcha. i suppose the editing locals functionality isnt really that important, the main reason i wanted to get it sorted out was that i was afraid my IDE / setup was somehow broken and itd be kinda dangerous to study with something that behaves unexpectantly / is broken (so that i dont study faulty information / methods).

may i ask what IDE you use? as you can probably tell im pretty new to rust so ive pretty much just been using whatever i see the people making tutorials use though i fear my installation (vsCode with rust-analyzer and CodeLLDB) might be faulty since my IntelliSense ignores things that obviously wont compile (it does catch them after ive attempted to run the faulty code but not whilst im writing it), sometimes it even suggests things that wont compile.

[iron birch]

Personally, I hardly ever use a debugger, and when I do, I read what the code is doing, I don't try to modify its execution. I find it far more useful to modify the program to print out useful information, because being in the middle of a serious debugger session is a nightmare of “okay, resume because this breakpoint was too soon … step forward … step forward … whoops too far, start over”. Logs hold still while you look at them.

VS Code + rust-analyzer is a perfectly fine choice and it's what I use.

my IntelliSense ignores things that obviously wont compile
this sounds like you might be editing a file that is not properly part of a Cargo project

or, actually, do you get to see problems if you save the file (without running it)?

[novel roost]

i made the project with cargo new sln1 🤔

[iron birch]

if so, that's normal; fully checking a Rust program requires running rustc, which is not cheap, so rust-analyzer only does it on save, not as you type

rust-analyzer has limited diagnostics of its own which do appear as you type

you can tell which is which because each message will either say rustc(...) or rust-analyzer(...), at the top right ish

also — as a beginner, you should in fact be looking at the error messages from cargo check or cargo run

VS Code is not capable of presenting the errors well — it doesn't have support for the kind of complex pointers and hints that rustc can produce

if you run cargo check in a terminal (or click the "click for full error message" thingy in VS Code, if you must), you will get messages that have been designed and formatted by the rustc team to be helpful

when you look at the VS Code problems pane, they get smashed into a list of lines that don't highlight the relevant code, just give you line and column numbers, which is much less helpful

[novel roost]

i tested this and yeah

[iron birch]

and the popular Error Lens extension gets you error messages in-line in the source code, but this isn't fully helpful either because it breaks apart a single error report into text scattered across the editor

so you really, really should be looking at cargo check

later, this is less necessary when you are more familiar with Rust

[novel roost]

thanks for telling me. ill do so instead then.

[iron birch]

but when you are beginning, you really should study the compiler's native error messages because they have been carefully crafted to explain things

later, you'll be more like "oh yeah I did that thing whoops" and you won't need all the hints all the time

[novel roost]

i guess its the oposite of the C compilers. they tell you a lot pre-compile but their error messages are often very cryptic

but yeah. ill start using cargo instead until im a bit more proficient. thank you once again for taking the time to explain these things to me