Replies: 1 comment 3 replies
-
|
If you go with the "codelldb.sh" approach, make sure to explicitly forward all necessary environment variables, as the debuggee is not executed as a child of codelldb.sh. |
Beta Was this translation helpful? Give feedback.
-
|
@vadimcn I have no idea which approach is the best to go with :) I saw it in the Do note that Clippy, as well as some Rust-internal tests disable the standard test harness, which means the standard [[test]]
name = "compile-test"
harness = falseP.S. See also ui_test crate -- the crate that functions as a custom harness to test-compile many rust internals |
Beta Was this translation helpful? Give feedback.
-
|
Moving "configurations": [
{
"env": {
"TESTNAME": "uninlined_format",
"LD_LIBRARY_PATH": "/home/nyurik/.rustup/toolchains/nightly-2025-01-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib"
},
"initCommands": [
"settings set target.process.follow-fork-mode child"
],
...This now shows the debugger at the program entry:
But it does not show any debug symbols, nor does it see any rust code. What's interesting is that breakpoints in Rust DO move to the right line, i.e. there are clearly some symbols loaded somewhere, but no breakpoint is ever hit. |
Beta Was this translation helpful? Give feedback.
-
|
Using the "cargo" property instead of "program" is intended to help determine the name of the test executable, which Cargo generates randomly. Note that it does not execute the test—only builds it. You still need to determine the necessary parameters and environment variables to pass to it. The codelldb.sh approach is an alternative that leverages Cargo’s runner override and could potentially be more automatic. However, the current example is likely failing to forward some parameters or environment variables into the launch configuration. It seemed to work when I originally wrote that section of the manual, but perhaps Clippy now requires something more. You'll need to do some legwork to figure out what's missing. ¯\(ツ)/¯ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
OS: Linux Mint 22 (Linux x64 6.8.0-52-generic)
VSCode version: Version: 1.96.4
CodeLLDB version: 1.11.3
Compiler: rustc 1.84.1, but clippy is compiled against the nightly
Debuggee:
cargo testTarget:
x86_64-unknown-linux-gnuI am trying to attach vscode dubugger to the a rust tool Clippy's test by running this command, and get an error that the
compile_testbinary is unable to loadlibrustc_driver.so(see exact error below).TESTNAME=uninlined_format cargo test --test compile-testNote that this unit test consists of thousands of individual compilation tests, thus is likely starting another sub-process to perform compilation of each.
Steps to Reproduce
git clone https://github.com/rust-lang/rust-clippy --recurse-submodules -j8cd rust-clippyTESTNAME=uninlined_format cargo test --test compile-test.cargo/config.tomland add a new section:.cargo/codelldb.shwith this content andchmod +xit. I assume this is the only way to pass the env varTESTNAMEto the vscode. Without this, Clippy runs thousands of tests.launch.json:Part that works OK (without debugger)
TESTNAME=uninlined_format cargo test --test compile-testrunnerconfiguration, the vscode is launched with the correct configuration. VSCode still gets called, and shows something like this in the new terminal window. Note that even if there are any debugging breakpoints in theclippy_lints/src/format_args.rs, debugger never stops. Thedebug consoleshows no errors.output
terminal output
debug output
See also the attached verbose_log1.txt
Part that fails (with debugger)
verbose log
/home/nyurik/.rustup/toolchains/nightly-2025-01-28-x86_64-unknown-linux-gnu/lib/home/nyurik/.rustup/toolchains/nightly-2025-01-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/libLD_LIBRARY_PATHinside the .config/codelldb.sh` but that had no effect:Beta Was this translation helpful? Give feedback.
All reactions