Repository navigation
Fix the remaining tests/debuginfo failures on msvc - #162598
Merged
Merged
Conversation
rustbot
added
A-LLVM
Collaborator
|
|
Contributor
Author
|
I guess i should also note, 23 support is not something i'm actively pursuing atm, the 23-based fixes are just to make sure we dont leave things that we know will break relatively soon. |
jieyouxu
reviewed
Sep 12, 2026
jieyouxu
approved these changes
Sep 12, 2026
Member
There was a problem hiding this comment.
Thanks, I also ran this locally.
@bors r+ rollup=never note="adjust dummy span debuginfo handling"
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Member
|
@bors p=6 scheduling |
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
merged-by-bors
Contributor
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 67e8d9d (parent) -> 6474e99 (this PR) Test differencesShow 547 test diffsStage 1
Stage 2
(and 445 additional test diffs) Additionally, 2 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 6474e999898cad2289175e2a7d253f5d0f574fa2 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (6474e99): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)Results (primary -0.6%, secondary -2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 493.573s -> 496.981s (0.69%) |
This was referenced Sep 14, 2026
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 19, 2026
Use spawned `SBDebugger` instance As mentioned in rust-lang#162598, this is a small forward-compatibility fix for `tests/debuginfo` with LLDB 23, which seems to be significantly less willing to let us use the parent LLDB instance. I assume this is due to not updating internal/python state while a command is actively being processed (the entire time `debugger_tester` is running, we're in a top-level `script` command)? We avoided this before because we need to be able to exit with a non-0 status code when not all the expected types/vars are tested, and it wasn't obvious how to get that to happen. Here, we use `os.kill(os.getpid(), signal.SIGTERM)`, which kills the parent LLDB process from within python. `SIGTERM` is used because `SIGKILL` is unix only, and `SIGABRT` spits out a huge LLDB backtrace with "report this error to LLDB", which is potentially confusing. The error exit behavior can be tested by deleting one of the `lldb-repr` lines from `tests/debuginfo/basic-types/main.rs` r? @Kobzol, @jieyouxu
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 19, 2026
Use spawned `SBDebugger` instance As mentioned in rust-lang#162598, this is a small forward-compatibility fix for `tests/debuginfo` with LLDB 23, which seems to be significantly less willing to let us use the parent LLDB instance. I assume this is due to not updating internal/python state while a command is actively being processed (the entire time `debugger_tester` is running, we're in a top-level `script` command)? We avoided this before because we need to be able to exit with a non-0 status code when not all the expected types/vars are tested, and it wasn't obvious how to get that to happen. Here, we use `os.kill(os.getpid(), signal.SIGTERM)`, which kills the parent LLDB process from within python. `SIGTERM` is used because `SIGKILL` is unix only, and `SIGABRT` spits out a huge LLDB backtrace with "report this error to LLDB", which is potentially confusing. The error exit behavior can be tested by deleting one of the `lldb-repr` lines from `tests/debuginfo/basic-types/main.rs` r? @Kobzol, @jieyouxu
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 19, 2026
Rollup merge of #162940 - Walnut356:alt_exit, r=Kobzol Use spawned `SBDebugger` instance As mentioned in #162598, this is a small forward-compatibility fix for `tests/debuginfo` with LLDB 23, which seems to be significantly less willing to let us use the parent LLDB instance. I assume this is due to not updating internal/python state while a command is actively being processed (the entire time `debugger_tester` is running, we're in a top-level `script` command)? We avoided this before because we need to be able to exit with a non-0 status code when not all the expected types/vars are tested, and it wasn't obvious how to get that to happen. Here, we use `os.kill(os.getpid(), signal.SIGTERM)`, which kills the parent LLDB process from within python. `SIGTERM` is used because `SIGKILL` is unix only, and `SIGABRT` spits out a huge LLDB backtrace with "report this error to LLDB", which is potentially confusing. The error exit behavior can be tested by deleting one of the `lldb-repr` lines from `tests/debuginfo/basic-types/main.rs` r? @Kobzol, @jieyouxu
pull Bot
pushed a commit
to xtqqczze/rust-lang-miri
that referenced
this pull request
Sep 20, 2026
Use spawned `SBDebugger` instance As mentioned in rust-lang/rust#162598, this is a small forward-compatibility fix for `tests/debuginfo` with LLDB 23, which seems to be significantly less willing to let us use the parent LLDB instance. I assume this is due to not updating internal/python state while a command is actively being processed (the entire time `debugger_tester` is running, we're in a top-level `script` command)? We avoided this before because we need to be able to exit with a non-0 status code when not all the expected types/vars are tested, and it wasn't obvious how to get that to happen. Here, we use `os.kill(os.getpid(), signal.SIGTERM)`, which kills the parent LLDB process from within python. `SIGTERM` is used because `SIGKILL` is unix only, and `SIGABRT` spits out a huge LLDB backtrace with "report this error to LLDB", which is potentially confusing. The error exit behavior can be tested by deleting one of the `lldb-repr` lines from `tests/debuginfo/basic-types/main.rs` r? @Kobzol, @jieyouxu
github-actions Bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Sep 21, 2026
Use spawned `SBDebugger` instance As mentioned in rust-lang/rust#162598, this is a small forward-compatibility fix for `tests/debuginfo` with LLDB 23, which seems to be significantly less willing to let us use the parent LLDB instance. I assume this is due to not updating internal/python state while a command is actively being processed (the entire time `debugger_tester` is running, we're in a top-level `script` command)? We avoided this before because we need to be able to exit with a non-0 status code when not all the expected types/vars are tested, and it wasn't obvious how to get that to happen. Here, we use `os.kill(os.getpid(), signal.SIGTERM)`, which kills the parent LLDB process from within python. `SIGTERM` is used because `SIGKILL` is unix only, and `SIGABRT` spits out a huge LLDB backtrace with "report this error to LLDB", which is potentially confusing. The error exit behavior can be tested by deleting one of the `lldb-repr` lines from `tests/debuginfo/basic-types/main.rs` r? @Kobzol, @jieyouxu
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the remainder of the failing tests from #161657
I used lldb 22.1 to individually check each of the
S_DEFRANGE_REGISTER_REL_INDIRnode (using e.g.llvm-pdbutil dump --symbols ".\build\x86_64-pc-windows-gnu\test\debuginfo\<test_name>.lldb\a.pdb" | rg "unknown \(4471\)")Any tests with an
unknown (4471)node (4471/0x1177 being the enum value forS_DEFRANGE_REGISTER_REL_INDIR) got an[msvc]revision to disable on LLDB older than 23.1.0.I then updated to LLDB 23.1.0 and disabled any remaining test failures that ocurred due to the variable shadowing behavior (so that they do not instantly break when we eventually run 23 in CI). Technically we could have avoided disabling those tests by using the python API to inspect individual slots of the frame, or by printing the whole frame at each step and matching against that, but the amount of effort seems not worth it until we determine whether or not LLDB can/will improve its behavior here..
One note, LLDB 23 seems to like it even less when we use the parent debugger instance for the test harness. I'll fix that in a followup PR since it requires a little bit of fiddling to get it to work with LLDB <23 (the short version is it's much harder to exit with a non-0 status code when using a nested debugger instance. We should be able to run something like
os.kill(os.getpid(), signal.SIGTERM)from the internal python to kill the parent LLDB process to work around that)There were a few fixes that required special handling
borrowed-basic.rs,basic-types-globals.rs,reference-debuginfo.rsLLDB appears to have changed their default formatting for chars again in v23.1.0 (
U+0x00000061 U'a'->U+0061 U'a') luckily these are similar enough that we can use a wildcard to pass in both casesdummy-span.rsThere was a conditional to prevent using the (0,0) default dummy span on MSVC with a comment explaining why (it would default to the first line of the file instead). I removed the
is_msvccheck and this test worked and didn't break anything else so, best guess this got fixed at some point and the comment was outdated?In any case, with this PR, the entirety of
tests/debuginfopasses onlinux-gnu,windows-gnu, andwindows-msvc🎉🎉r? @Kobzol, @jieyouxu