[lldb][Formatter] Get element type for unordered_maps from __hash_table::value_type #144517
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
…le::value_type llvm#143501 changes usage of `__hash_value_type` in libcxx to an empty tag type. This type will no longer have a definition in DWARF. Currently the LLDB unordered_map formatter deduces the map's `element_type` by looking at the `__cc_` member of `__hash_value_type`. But that will no longer work because we only have its forward declaration. Since what we're really after is the type that `__hash_value_type` is wrapping, we can just look at the `__hash_table::value_type` typedef. With llvm#143501 that will now point to the `std::pair` element type (which used to be what we got from `__cc_`). TBD: need to double-check this works for older layouts. Quick glance at the code makes me suspicious of cases like `unordered_map<std::pair<int, int>, int>`
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
labath
approved these changes
Jun 17, 2025
There was a problem hiding this comment.
I think that should work. One thing to look out for when it comes to typedefs is that they are not emitted if they aren't used (in the compilation unit). It should be fine as long as the type is referenced from a non-template member function, and I think that should be the case with the basic form of the insert method. (references from template member fn's are not enough as these are also only emitted when used)
|
To be on the safe side I added an early-return for the new layout. Technically it would work for old layouts even without this early-return, but it kind of only worked by chance. This way regardless of what the |
Michael137
added a commit
to swiftlang/llvm-project
that referenced
this pull request
Jun 18, 2025
…le::value_type (llvm#144517) llvm#143501 changes usage of `__hash_value_type` in libcxx to an empty tag type. This type will no longer have a definition in DWARF. Currently the LLDB unordered_map formatter deduces the map's `element_type` by looking at the `__cc_` member of `__hash_value_type`. But that will no longer work because we only have its forward declaration. Since what we're really after is the type that `__hash_value_type` is wrapping, we can just look at the `__hash_table::value_type` typedef. With llvm#143501 that will now point to the `std::pair` element type (which used to be what we got from `__cc_`). TBD: need to double-check this works for older layouts. Quick glance at the code makes me suspicious of cases like `unordered_map<std::pair<int, int>, int>` (cherry picked from commit 382e3fd)
fschlimb
pushed a commit
to fschlimb/llvm-project
that referenced
this pull request
Jun 18, 2025
…le::value_type (llvm#144517) llvm#143501 changes usage of `__hash_value_type` in libcxx to an empty tag type. This type will no longer have a definition in DWARF. Currently the LLDB unordered_map formatter deduces the map's `element_type` by looking at the `__cc_` member of `__hash_value_type`. But that will no longer work because we only have its forward declaration. Since what we're really after is the type that `__hash_value_type` is wrapping, we can just look at the `__hash_table::value_type` typedef. With llvm#143501 that will now point to the `std::pair` element type (which used to be what we got from `__cc_`). TBD: need to double-check this works for older layouts. Quick glance at the code makes me suspicious of cases like `unordered_map<std::pair<int, int>, int>`
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.
#143501 changes usage of
__hash_value_typein libcxx to an empty tag type. This type will no longer have a definition in DWARF. Currently the LLDB unordered_map formatter deduces the map'selement_typeby looking at the__cc_member of__hash_value_type. But that will no longer work because we only have its forward declaration. Since what we're really after is the type that__hash_value_typeis wrapping, we can just look at the__hash_table::value_typetypedef. With #143501 that will now point to thestd::pairelement type (which used to be what we got from__cc_).TBD: need to double-check this works for older layouts. Quick glance at the code makes me suspicious of cases like
unordered_map<std::pair<int, int>, int>