[all-commits] [llvm/llvm-project] b4274c: [DebugInfo] When referencing structured bindings u...
David Blaikie via All-commits
all-commits at lists.llvm.org
Mon Sep 8 00:38:27 PDT 2025
Branch: refs/heads/release/21.x
Home: https://github.com/llvm/llvm-project
Commit: b4274c3bc8eee764ad048c77b9a4baa12eb708a0
https://github.com/llvm/llvm-project/commit/b4274c3bc8eee764ad048c77b9a4baa12eb708a0
Author: David Blaikie <dblaikie at gmail.com>
Date: 2025-09-08 (Mon, 08 Sep 2025)
Changed paths:
M clang/lib/CodeGen/CGCall.cpp
M clang/lib/CodeGen/CGCall.h
M clang/lib/CodeGen/CGExpr.cpp
M clang/test/CodeGenCXX/debug-info-structured-binding.cpp
Log Message:
-----------
[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?
(cherry picked from commit 665e875f1a86be650e044bb20744bb272d03e11d)
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list