-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[LLDB] List structured bindings as frame variables #122028
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@llvm/issue-subscribers-lldb Author: Ethan Ordentlich (Skynet0)
In reference to the C++17 feature <https://en.cppreference.com/w/cpp/language/structured_binding>.
I've searched quite a bit, but haven't found a thread discussing this on Discourse or GitHub. I have the following program: #include <map>
int main() {
std::map<int, int> m = {{0, 1}, {2, 3}};
int t = 0;
for (const auto& [k, v] : m) {
t += v;
}
} Running LLDB:
Inside the loop, I'd expect to see Developing on an M2 Macbook Pro. Compiler:
LLDB: |
Looks like we're still marking
which LLDB will omit from This should've been addressed by #48909, but looks like it doesn't quite work for this case |
This happens because
As opposed to following
It looks like |
Self-contained reproducer:
|
… for std::get free function When we generate the debug-info for a `VarDecl` we try to determine whether it was introduced as part of a structure binding (aka a "holding var"). If it was, we don't mark it as `artificial`. The heuristic to determine a holding var uses `IgnoreUnlessSpelledInSource` to unwrap the `VarDecl` initializer until we hit a `DeclRefExpr` that refers to a `Decomposition`. For "tuple-like decompositions", Clang will generate a call to a `template<size_t I> Foo get(Bar)` function that retrieves the `Ith` element from the tuple-like structure. If that function is a member function, we get an AST that looks as follows: ``` VarDecl implicit used z1 'std::tuple_element<0, B>::type &&' cinit `-ExprWithCleanups <col:10> 'int' xvalue `-MaterializeTemporaryExpr <col:10> 'int' xvalue extended by Var 0x11d110cf8 'z1' 'std::tuple_element<0, B>::type &&' `-CXXMemberCallExpr <col:10> 'int' `-MemberExpr <col:10> '<bound member function type>' .get 0x11d104390 `-ImplicitCastExpr <col:10> 'B' xvalue <NoOp> `-DeclRefExpr <col:10> 'B' lvalue Decomposition 0x11d1100a8 '' 'B' ``` `IgnoreUnlessSpelledInSource` happily unwraps this down to the `DeclRefExpr`. However, when the `get` helper is a free function (which it is for `std::pair` in libc++ for example), then the AST is: ``` VarDecl col:16 implicit used k 'std::tuple_element<0, const std::tuple<int, int>>::type &' cinit `-CallExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type':'const int' lvalue adl |-ImplicitCastExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(*)(const tuple<int, int> &) noexcept' <FunctionToPointerDecay> | `-DeclRefExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' lvalue Function 0x1210262d8 'get' 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' (FunctionTemplate 0x11d068088 'get') `-DeclRefExpr <col:16> 'const std::tuple<int, int>' lvalue Decomposition 0x121021518 '' 'const std::tuple<int, int> &' ``` `IgnoreUnlessSpelledInSource` doesn't unwrap this `CallExpr`, so we incorrectly mark the binding as `artificial` in debug-info. This patch adjusts our heuristic to account for `CallExpr` nodes. Fixes llvm#122028
… for std::get free function When we generate the debug-info for a `VarDecl` we try to determine whether it was introduced as part of a structure binding (aka a "holding var"). If it was, we don't mark it as `artificial`. The heuristic to determine a holding var uses `IgnoreUnlessSpelledInSource` to unwrap the `VarDecl` initializer until we hit a `DeclRefExpr` that refers to a `Decomposition`. For "tuple-like decompositions", Clang will generate a call to a `template<size_t I> Foo get(Bar)` function that retrieves the `Ith` element from the tuple-like structure. If that function is a member function, we get an AST that looks as follows: ``` VarDecl implicit used z1 'std::tuple_element<0, B>::type &&' cinit `-ExprWithCleanups <col:10> 'int' xvalue `-MaterializeTemporaryExpr <col:10> 'int' xvalue extended by Var 0x11d110cf8 'z1' 'std::tuple_element<0, B>::type &&' `-CXXMemberCallExpr <col:10> 'int' `-MemberExpr <col:10> '<bound member function type>' .get 0x11d104390 `-ImplicitCastExpr <col:10> 'B' xvalue <NoOp> `-DeclRefExpr <col:10> 'B' lvalue Decomposition 0x11d1100a8 '' 'B' ``` `IgnoreUnlessSpelledInSource` happily unwraps this down to the `DeclRefExpr`. However, when the `get` helper is a free function (which it is for `std::pair` in libc++ for example), then the AST is: ``` VarDecl col:16 implicit used k 'std::tuple_element<0, const std::tuple<int, int>>::type &' cinit `-CallExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type':'const int' lvalue adl |-ImplicitCastExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(*)(const tuple<int, int> &) noexcept' <FunctionToPointerDecay> | `-DeclRefExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' lvalue Function 0x1210262d8 'get' 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' (FunctionTemplate 0x11d068088 'get') `-DeclRefExpr <col:16> 'const std::tuple<int, int>' lvalue Decomposition 0x121021518 '' 'const std::tuple<int, int> &' ``` `IgnoreUnlessSpelledInSource` doesn't unwrap this `CallExpr`, so we incorrectly mark the binding as `artificial` in debug-info. This patch adjusts our heuristic to account for `CallExpr` nodes. Fixes llvm#122028
In reference to the C++17 feature https://en.cppreference.com/w/cpp/language/structured_binding.
I've searched quite a bit, but haven't found a thread discussing this on Discourse or GitHub.
I have the following program:
Running LLDB:
Inside the loop, I'd expect to see
k
andv
asint&
. Instead, I need to manually evaluate them, also in the frame.Developing on an M2 Macbook Pro.
Compiler:
LLDB:
lldb version 19.1.6
The text was updated successfully, but these errors were encountered: