🍒 [swift/release/6.2][lldb] Assortment of cherry-picks related to data-formatters #11052
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
|
@swift-ci test |
|
@swift-ci windows |
adrian-prantl
approved these changes
Jul 23, 2025
Michael137
force-pushed
the
lldb/cherry-picks-to-6.2
branch
from
1103190 to
e67bc1c
Compare
|
@swift-ci test |
|
@swift-ci test windows |
`SBType::GetBasicType` fails on typedefs to primitive types. The docs for `GetBasicType` state: ``` Returns the BasicType value that is most appropriate to this type ``` But, e.g., for `uint64_t` this would currently return `eBasicTypeInvalid`. `TypeSystemClang::GetBasicTypeEnumeration` (which is what `SBType::GetBasicType` uses) doesn't see through typedefs. Inside LLDB we almost always call `GetBasicTypeEnumeration` on the canonical type. In the cases we don't I suspect those were just subtle bugs. This patch gets the canonical type inside of `GetBasicTypeEnumeration` instead. rdar://155829208 (cherry picked from commit b7889a6)
Deeply nested structs can be noisy, so Apple's LLDB fork sets the default to `4`: https://github.com/swiftlang/llvm-project/blob/9c93adbb283005ab416fd155b75fd43e6a8288ca/lldb/source/Target/TargetProperties.td#L134-L136 Thought it would be useful to upstream this. Though happy to pick a different default or keep it as-is. (cherry picked from commit 1e7ec35)
Fixes test on Windows. Same reason as llvm#149322 (cherry picked from commit b826429)
) When dumping variables, LLDB will print a one-time warning about truncating children (when the children count exceeds the default `target.max-children-count`). But we only do this for `frame variable`. So if we use `dwim-print` or `expression`, the output gets truncated but we don't print a warning. But because we store the fact that we truncated some output on the `CommandInterpreter`, we fire the warning next time we use `frame variable`. E.g.,: ``` (lldb) p arr (int[1000]) { [0] = -5 [1] = 0 [2] = 0 <-- snipped --> [253] = 0 [254] = 0 [255] = 0 ... } (lldb) v someLocal (int) someLocal = 10 *** Some of the displayed variables have more members than the debugger will show by default. To show all of them, you can either use the --show-all-children option to frame variable or raise the limit by changing the target.max-children-count setting. ``` This patch prints the warning for `dwim-print` and `expression`. I only added a test for the `target.max-children-count` for now because it seems the `target.max-children-depth` warning is broken (I can't get it to fire). (cherry picked from commit 8c28f49)
(cherry picked from commit 4797a6c)
…dered_map (llvm#145872) Desugar any potential references/typedefs before checking `isStdTemplate`. Previously, the typename might've been: ``` const std::unordered_map<...> & ``` for references. This patch gets the pointee type before grabbing the canonical type. `GetNonReferenceType` will unwrap typedefs too, so we should always end up with a non-reference before we get to `GetCanonicalType`. llvm#145847
…lvm#146909) The only difference is that with libc++ the summary string contains the derefernced pointer value. With libstdc++ we currently display the pointer itself, which seems redundant. E.g., ``` (std::unique_ptr<int>) iup = 0x55555556d2b0 { pointer = 0x000055555556d2b0 } (std::unique_ptr<std::basic_string<char> >) sup = 0x55555556d2d0 { pointer = "foobar" } ``` This patch moves the logic into a common helper that's shared between the libc++ and libstdc++ formatters. After this patch we can combine the libc++ and libstdc++ API tests (see llvm#146740). (cherry picked from commit a89e232)
…weak_ptr (llvm#147033) For the `__shared_owners_` we need to add `+1` to the count, but for `__shared_weak_owners_` the value reflects the exact number of weak references. (cherry picked from commit 32946eb)
…rs consistent with each other (llvm#147165) This patch adjusts the libcxx and libstdcxx std::shared_ptr formatters to look the same. Changes to libcxx: * Now creates a synthetic child called `pointer` (like we already do for `std::unique_ptr`) Changes to libstdcxx: * When asked to dereference the pointer, cast the type of the result ValueObject to the element type (which we get from the template argument to std::shared_ptr). Before: ``` (std::__shared_ptr<int, __gnu_cxx::_S_atomic>::element_type) *foo = 123 ``` After: ``` (int) *foo = 123 ``` Tested in llvm#147141 (cherry picked from commit 6fec6a9)
…er tests into generic test (llvm#147031) The libc++ test was a subset of the tests in libstdc++. This test moves the libc++ test into `generic` and somne additional test-cases from `libstdc++` (specifically the recursive unique_ptr case). It turns out the libstdc++ formatter supports dereferencing using the "object" or "obj" names. We could either drop those from the tests or support the same for libc++. I took the latter approach but don't have strong opinions on this. Split out from llvm#146740 (cherry picked from commit 074ccde)
… summary (llvm#147166) Depends on llvm#147165 This adds weak/strong counts to the std::shared_ptr summary of the libstdcxx formatters. We already do this for libcxx. This will make it easier to consolidate the tests into a generic one (see llvm#147141). (cherry picked from commit 40fb90e)
…generic test (llvm#147141) This combines the libc++ and libstdc++ test cases. The libstdcpp tests were a subset of the libc++ test, so this patch moves the libcxx test into `generic` and removes the libstdcpp test entirely. Split out from llvm#146740 (cherry picked from commit e14e982)
…hared_ptr formatters (llvm#147340) Follow-up to llvm#147165 (review) Currently when we explicitly dereference a std::shared_ptr, both the libstdc++ and libc++ formatters will cast the type of the synthetic pointer child to whatever the `std::shared_ptr::element_type` is aliased to. E.g., ``` (lldb) v p (std::shared_ptr<int>) p = 10 strong=1 weak=0 { pointer = 0x000000010016c6a0 } (lldb) v *p (int) *p = 10 ``` However, when we print (or dereference) `p.pointer`, the type devolves to something less user-friendly: ``` (lldb) v p.pointer (std::shared_ptr<int>::element_type *) p.pointer = 0x000000010016c6a0 (lldb) v *p.pointer (std::shared_ptr<int>::element_type) *p.pointer = 10 ``` This patch changes both formatters to store the casted type. Then `GetChildAtIndex` will consistently use the unwrapped type. (cherry picked from commit f999918)
The formatters for these have been reworked in recent patches. (cherry picked from commit 912ab52)
By not forcing the DWARF debug info format. When left as the default, the tests pass. Test added by llvm#149088. (cherry picked from commit 4bf82ae)
Michael137
force-pushed
the
lldb/cherry-picks-to-6.2
branch
from
e67bc1c to
39c63d1
Compare
|
@swift-ci test |
|
@swift-ci test windows |
|
@swift-ci test Windows |
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.
No description provided.