[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