Add LLDB providers for BTreeMap and BTreeSet #140130
Open
+165
−0
Conversation
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
|
rustbot has assigned @Mark-Simulacrum. Use |
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
ede1998
force-pushed
the
add-lldb-btree-providers
branch
from
687620b to
950f608
Compare
|
@rustbot author |
rustbot
added
S-waiting-on-author
|
Reminder, once the PR becomes ready for a review, use |
ede1998
force-pushed
the
add-lldb-btree-providers
branch
from
e792e29 to
bb58d72
Compare
rustbot
added
A-compiletest
This comment has been minimized.
This comment has been minimized.
ede1998
force-pushed
the
add-lldb-btree-providers
branch
from
bb58d72 to
f5148c7
Compare
ede1998
force-pushed
the
add-lldb-btree-providers
branch
from
f5148c7 to
53ef2e0
Compare
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
rustbot
added
the
S-waiting-on-review
|
@rustbot ready |
|
@bors r+ |
bors
added
S-waiting-on-bors
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
May 15, 2025
…r=Mark-Simulacrum Add LLDB providers for BTreeMap and BTreeSet Fixes rust-lang#111868. I'm unsure what the supported LLDB versions for `rust-lldb` are. I tested with LLDB 18 and 19 and it works with those but I know that it does not work with LLDB 14 which was picked by my `codelldb` extension for some reason (even though it packages LLDB 19). I also had to work around what seems like an LLDB bug to me. Otherwise, I'd have kept the code more similar to the GDB provider. `SBTarget.FindFirstType()` does not find the types that I'm searching for (`LeafNode<i32, i32>*`): ``` target = node.GetTarget() print("leaf type:", node.GetType()) internal_type = target.FindFirstType(node.GetType().GetName()) print("Actual type:", internal_type) ``` which prints ``` leaf type: struct alloc::collections::btree::node::LeafNode<int, int> * Actual type: No value ``` All in all, my experience with LLDB debug provider was very fiddly/they seem to break easily but I think it would be better to have `BTreeMap`/`BTreeSet` providers than not have them. Getting to run the `debuginfo` tests was a pain too because of rust-lang#126092 and errors with `import _lldb` (rust-lang#123621). I ended up re-compling lldb from source against python 3.10 because the tests don't work if lldb is compiled against python 3.12. Also, it seems like the tests are not run in CI? At least I had a test commit in the PR before to trigger a `debuginfo` test failure which I didn't see here in my PR.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 15, 2025
…mpiler-errors Rollup of 14 pull requests Successful merges: - rust-lang#139749 (docs(library/core/src/pin): fix typo "necessarily" -> "necessary") - rust-lang#140130 (Add LLDB providers for BTreeMap and BTreeSet) - rust-lang#140685 (Simplify `Vec::as_non_null` implementation and make it `const`) - rust-lang#140712 (normalization: avoid incompletely constraining GAT args) - rust-lang#140768 (Improve `dangerous_implicit_aurorefs` diagnostic output) - rust-lang#140834 (move (or remove) some impl Trait tests) - rust-lang#140910 (Remove `stable` attribute from wasi fs (read_exact|write_all)_at) - rust-lang#140947 (Flush errors before deep normalize in `dropck_outlives`) - rust-lang#140966 (Remove #![feature(let_chains)] from library and src/librustdoc) - rust-lang#140977 ([win] Use a dash instead of slash for linker to avoid breaking lld) - rust-lang#140990 (VxWorks: updates from recent libc versions) - rust-lang#141003 (Improve ternary operator recovery) - rust-lang#141013 (Implement methods to set STARTUPINFO flags for Command API on Windows) - rust-lang#141026 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup
|
Failed in a rollup #141041 (comment) @bors r- |
bors
added
S-waiting-on-author
|
@compiler-errors What happened? Did my PR fail CI? I cannot find any logs that show why the PR was not merged or what went wrong. What do I have to do? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #111868.
I'm unsure what the supported LLDB versions for
rust-lldbare. I tested with LLDB 18 and 19 and it works with those but I know that it does not work with LLDB 14 which was picked by mycodelldbextension for some reason (even though it packages LLDB 19).I also had to work around what seems like an LLDB bug to me. Otherwise, I'd have kept the code more similar to the GDB provider.
SBTarget.FindFirstType()does not find the types that I'm searching for (LeafNode<i32, i32>*):which prints
All in all, my experience with LLDB debug provider was very fiddly/they seem to break easily but I think it would be better to have
BTreeMap/BTreeSetproviders than not have them.Getting to run the
debuginfotests was a pain too because of #126092 and errors withimport _lldb(#123621).I ended up re-compling lldb from source against python 3.10 because the tests don't work if lldb is compiled against python 3.12.
Also, it seems like the tests are not run in CI? At least I had a test commit in the PR before to trigger a
debuginfotest failure which I didn't see here in my PR.