Rust Visualization for enum doesn't seem to be working

[sontek]

OS: MacOS 13.5.2 (22G91) VSCode version: Version: 1.82.2 (Universal) CodeLLDB version: v1.10.0 Compiler: cargo Debuggee: Rust binary built with cargo build

>  file target/debug/rubrika
target/debug/rubrika: Mach-O 64-bit executable arm64

I'm debugging some rust code using VSCode + CodeLLDB and some of the visualizations show no values:

This is my launch configuration:

 {
            "type": "lldb",
            "request": "launch",
            "name": "Debug executable 'rubrika'",
            "cargo": {
                "env": {
                    "RUSTFLAGS": "-g",
                    "CARGO_HOME": "/Users/johnanderson/.local/share/rtx/installs/rust/1.72.0/",
                    "RUSTUP_HOME": "/Users/johnanderson/.local/share/rtx/installs/rust/1.72.0/",
                },
                "args": [
                    "build",
                ],
            },
            "args": [
                "server",
                "--port",
                "8800",
                "--log-level",
                "debug"
            ],
            "sourceLanguages": ["rust"],
            "cwd": "${workspaceFolder}",
        },

I was expecting to see that the payload_type.Ok.0 is of value PullRequest but I wasn't able to do that. Here is a screenshot of RustRover debugging the same code:

This might be a limitation of lldb but not sure. If I print the variable in Debug Console it prints:

p payload_type
(core::result::Result<rubrika::vcs::github::types::PayloadType, core::convert::Infallible>) Infallible>{...} {
  Ok = {
    0 = {}
  }
  Err = (0 = core::convert::Infallible @ 0x0000000171883a80)
}

My system has:

❯ lldb --version
lldb-1500.0.22.8
Apple Swift version 5.9 (swiftlang-5.9.0.128.108 clang-1500.0.40.1)

I've also installed a custom version:

❯ lldb --version
lldb version 17.0.1

but I have no idea how to tell the plugin to use these versions.

[sontek]

This might be a duplicate of:

https://github.com/vadimcn/codelldb/issues/827

The weird thing is that RustRover uses lldb as well and doesn't have any issue.

(lldb) version
lldb version 16.0.0 (JetBrains IDE bundle; build 383)

(lldb) p payload_type
(core::result::Result<rubrika::vcs::github::types::PayloadType, core::convert::Infallible>) payload_type = {
  Ok = {
    0 = {}
  }
  Err = (0 = core::convert::Infallible @ 0x000000016ca8fa80)
}

but with CodeLLDB:

(lldb) version
lldb version 17.0.0-custom
  rust-enabled

(lldb)  p payload_type
(core::result::Result<rubrika::vcs::github::types::PayloadType, core::convert::Infallible>) Infallible>{...} {
  Ok = {
    0 = {}
  }
  Err = (0 = core::convert::Infallible @ 0x0000000171883a80)
}

[sontek]

Looks like LLDB added support for rust enums here:

https://github.com/llvm/llvm-project/commit/e84751a21561c5b1d5673cdff8e22ac4cf2f5dc2

Which isn't in a real release yet. So might be worth applying that patch to the CodeLLDB lldb?

Can I provide my own lldb to the plugin?

[alexkirsz]

I can confirm that latest LLDB built from source properly displays Rust enums.

lldb version 18.0.0git (https://github.com/llvm/llvm-project.git revision e4384149b58f7c3d19c5d38bc46038c660b77ca9)
  clang revision e4384149b58f7c3d19c5d38bc46038c660b77ca9
  llvm revision e4384149b58f7c3d19c5d38bc46038c660b77ca9

(lldb) var
(lldb_example::Enum) v = {
  $variants$ = {
    $variant$0 = {
      $discr$ = 0
      value = (__0 = 0)
    }
    $variant$ = {
      value = {
        __0 = {
          vec = {
            buf = {
              ptr = {
                pointer = (pointer = 0x0000000000000000)
                _marker = {}
              }
              cap = 0
              alloc = {}
            }
            len = 271540913897472
          }
        }
      }
    }
  }
}

As of today, neither the version packaged with CodeLLDB nor the default that comes with Xcode do.

(lldb) var
(lldb_example::Enum) v = {}

I tried to build a new version of the extension with the new version but I'm running into a SIGSEGV as soon as I try to debug a program.

Received signal: SIGSEGV
   0: backtrace::backtrace::libunwind::trace
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/backtrace/libunwind.rs:93:5
      backtrace::backtrace::trace_unsynchronized
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/backtrace/mod.rs:66:5
   1: backtrace::backtrace::trace
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/backtrace/mod.rs:53:14
   2: backtrace::capture::Backtrace::create
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/capture.rs:176:9
   3: backtrace::capture::Backtrace::new
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/capture.rs:140:22
   4: codelldb::hook_crashes::handler
             at /Users/alex/dev/codelldb/adapter/codelldb/src/lib.rs:140:18
   5: __platform_memmove
   6: _ZL39__cpp_closure_12014989057349851046_implv
             at /Users/alex/dev/codelldb/adapter/lldb/src/sb/sbcommandreturnobject.rs:10:20
   7: __cpp_closure_12014989057349851046
             at /Users/alex/dev/codelldb/adapter/lldb/src/sb/sbcommandreturnobject.rs:15:45
   8: lldb::sb::sbcommandreturnobject::SBCommandReturnObject::new
             at /Users/alex/dev/codelldb/adapter/lldb/src/sb/sbcommandreturnobject.rs:9:9
   9: codelldb::python::initialize
             at /Users/alex/dev/codelldb/adapter/codelldb/src/python.rs:90:30
  10: codelldb::debug_session::DebugSession::run
             at /Users/alex/dev/codelldb/adapter/codelldb/src/debug_session.rs:117:45
  11: codelldb::run_debug_session::{{closure}}
             at /Users/alex/dev/codelldb/adapter/codelldb/src/lib.rs:123:23
  12: codelldb::debug_server::{{closure}}
             at /Users/alex/dev/codelldb/adapter/codelldb/src/lib.rs:95:82
  13: tokio::runtime::park::CachedParkThread::block_on::{{closure}}
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/park.rs:282:63
  14: tokio::runtime::coop::with_budget
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/coop.rs:107:5
      tokio::runtime::coop::budget
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/coop.rs:73:5
      tokio::runtime::park::CachedParkThread::block_on
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/park.rs:282:31
  15: tokio::runtime::context::blocking::BlockingRegionGuard::block_on
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/context/blocking.rs:66:9
  16: tokio::runtime::scheduler::multi_thread::MultiThread::block_on::{{closure}}
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/scheduler/multi_thread/mod.rs:87:13
  17: tokio::runtime::context::runtime::enter_runtime
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/context/runtime.rs:65:16
  18: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/scheduler/multi_thread/mod.rs:86:9
  19: tokio::runtime::runtime::Runtime::block_on
             at /Users/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.32.0/src/runtime/runtime.rs:349:45
  20: codelldb::debug_server
             at /Users/alex/dev/codelldb/adapter/codelldb/src/lib.rs:85:5
  21: codelldb::main
  22: core::ops::function::FnOnce::call_once
  23: std::sys_common::backtrace::__rust_begin_short_backtrace
  24: std::rt::lang_start::{{closure}}
  25: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/core/src/ops/function.rs:284:13
      std::panicking::try::do_call
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/std/src/panicking.rs:524:40
      std::panicking::try
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/std/src/panicking.rs:488:19
      std::panic::catch_unwind
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/std/src/panic.rs:142:14
      std::rt::lang_start_internal::{{closure}}
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/std/src/rt.rs:148:48
      std::panicking::try::do_call
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/std/src/panicking.rs:524:40
      std::panicking::try
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/std/src/panicking.rs:488:19
      std::panic::catch_unwind
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/std/src/panic.rs:142:14
      std::rt::lang_start_internal
             at /rustc/28eb857b9504bd05bbed0cf8af8e825fbdbb1fa1/library/std/src/rt.rs:148:20
  26: std::rt::lang_start
  27: _main

[alexkirsz]

cc @vadimcn Would it be possible to update the LLDB version packaged with CodeLLDB to include the fix for Rust enums? 🙂

[MolotovCherry]

I don't know if it's only me, but this is how enums display for me (has been this way for awhile). I have the latest extension version of course. let foo = Ok::<_, ()>("bar");

[stijnfrishert]

Can confirm this is an issue on my system as well 👍

[vadimcn]

@sontek: Is your enum definition recursive? Is so, this is a dupe of #827

@MolotovCherry: enums in -windows-msvc target are known to be broken: #839, which has a different cause.

[MolotovCherry]

@sontek: Is your enum definition recursive? Is so, this is a dupe of #827

@MolotovCherry: enums in -windows-msvc target are known to be broken: #839, which has a different cause.

I think so. I am using the same target you mentioned as well. Sounds like that's probably the cause.