33

I've set up the Visual Studio Code debugger and run the following program.

pub fn main() {
    let mut chars = "test".chars();
    match chars.next() {
        Some(c) => {
            println!("What is the value of c, here?");
            if c == 'c' {
                println!("c");
            }
        }
        None => {}
    }
}

If I set a breakpoint at line 6, and look in the Variables and Watch panes, c does not evaluate, but rather passes the following message: identifier 'c' is undefined using cppvsdbg on Windows, or <not available> using lldb on Linux. I've confirmed that this happens both on Linux and Windows builds, for the current stable compiler version.

I've also added the following to Cargo.toml to no avail:

[profile.dev]
opt-level = 0
debug = true

For reference, here is my launch.json file, needed for the VS Code compiler:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(Windows) Launch",
            "type": "cppvsdbg",
            "request": "launch",
            "program": "${workspaceFolder}/target/debug/test.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true
        }
    ]
}

Replace "(Windows) Launch" with your OS of choice.

Why is this the result? Is there a fix, or are there some compiler options that should be added?

Christopher Ronning
  • 1,875
  • 3
  • 19
  • 28
  • Not sure if it would work but potentially redeclaring `let c = c;` might make that variable available to the debugger? – Frxstrem Jun 09 '19 at 22:53
  • @Frxstrem Thanks for the suggestion! I tried that, and it did not seem to make a difference. Either way, I would love to find a solution that does not require extra boilerplate. – Christopher Ronning Jun 09 '19 at 22:56
  • 7
    LLDB doesn't yet support a number of Rust concepts. It can't understand enums, and apparently can't understand `char` either. – Peter Hall Jun 10 '19 at 10:39
  • @PeterHall That is unfortunate. Are you aware of another GNU toolchain that supports these features? Or barring that, any clue if there's a roadmap for this type of support? – Christopher Ronning Jun 10 '19 at 18:49
  • 3
    `rust-gdb` is able to print the value: `$ rust-gdb target/debug/pr`, then `(gdb) br main.rs:6`, `(gdb) run`, and when it stops `(gdb) print c` shows: `$1 = 116 't'`. – rodrigo Jun 10 '19 at 19:19
  • 1
    Possibly related: [rls-vscode#509 `Option` variables show "" even when clearly set](https://github.com/rust-lang/rls-vscode/issues/509) – Jeremy Jun 10 '19 at 19:20
  • 1
    I'm not necessarily able to dig deep into this right now, but this is possibly related too: https://stackoverflow.com/questions/36621130/how-can-i-inspect-variable-values-while-debugging-msvc-abi-rust-programs?rq=1 – Christopher Ronning Jun 10 '19 at 20:15
  • 2
    Orthogonal to your direct question, but an `if let` would be more idiomatic than a `match` in this code. – Shepmaster Jun 12 '19 at 18:21
  • Have you ever run any rust code on vscode before or it's the first time? I mean, if it's the first time, there may be some problem setting up the extension. – amirali Jun 12 '19 at 19:24
  • 1
    Same experience as OP on mac – stacksonstacks Jun 17 '19 at 01:25
  • 1
    Please change the title to include that fact that its VSCode and not Visual Studio. – Refael Sheinker Jun 16 '21 at 10:17
  • Good call, thanks @RefaelSheinker – Christopher Ronning Aug 02 '21 at 19:11

2 Answers2

1

This issue is not reproducible with recent release of CodeLLDB.

CodeLLDB v1.7.0
rust : 1.60.0 (7737e0b5c 2022-04-04)
vscode: v1.67.0

Everything works as expected the debug view shows

iter: {end:0x000055555559105f}
c: 't'

Upgrading the codelldb to specified version will resolve the issue.

Arjun
  • 3,248
  • 18
  • 35
0

I posted a working configuration that supports vscode + rust documented here:

https://dev.to/elasticdotventures/vscode-debug-rust-198m

Chayim Friedman
  • 47,971
  • 5
  • 48
  • 77
Brian Horakh
  • 329
  • 4
  • 12