summaryrefslogtreecommitdiff
path: root/lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
diff options
context:
space:
mode:
authorDavid Blaikie <dblaikie@gmail.com>2025-09-02 14:03:58 -0700
committerGitHub <noreply@github.com>2025-09-02 21:03:58 +0000
commit665e875f1a86be650e044bb20744bb272d03e11d (patch)
tree4a28f777685bd58931a11a684e6f89c003832946 /lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
parent3c7bf3b3c3a4871d13f7b7d5d60bbf190eaf8f3a (diff)
[DebugInfo] When referencing structured bindings use the reference's location, not the binding's declaration's location (#153637)
For structured bindings that use custom `get` specializations, the resulting LLVM IR ascribes the load of the result of `get` to the binding's declaration, rather than the place where the binding is referenced - this caused awkward sequencing in the debug info where, when stepping through the code you'd step back to the binding declaration every time there was a reference to the binding. To fix that - when we cross into IRGening a binding - suppress the debug info location of that subexpression. I don't represent this as a great bit of API design - certainly open to ideas, but putting it out here as a place to start. It's /possible/ this is an incomplete fix, even - if the binding decl had other subexpressions, those would still get their location applied & it'd likely be wrong. So maybe that's a direction to go with to productionize this - add a new location scoped device that suppresses any overriding - this might be more robust. How do people feel about that?
Diffstat (limited to 'lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py')
0 files changed, 0 insertions, 0 deletions