You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[clang][DebugInfo] Don't mark structured bindings as artificial (#100355)
This patch is motivated by the debug-info issue in
#48909. Clang is currently
emitting the `DW_AT_artificial` attribute on debug-info entries for
structured bindings whereas GCC does not. GCC's interpretation of the
DWARF spec is more user-friendly in this regard, so we would like to do
the same in Clang. [`CGDebugInfo` uses `isImplicit` to decide which
variables to mark
artificial](https://github.com/llvm/llvm-project/blob/0c4023ae3b64c54ff51947e9776aee0e963c5635/clang/lib/CodeGen/CGDebugInfo.cpp#L4783-L4784)
(e.g., `ImplicitParamDecls`, compiler-generated variables, etc.). But
for the purposes of debug-info, when we say "artificial", what we really
mean in many cases is: "not explicitly spelled out in source".
`VarDecl`s that back tuple-like bindings are [technically
compiler-generated](#48909 (comment)),
but that is a confusing notion for debug-info, since these bindings
*are* spelled out in source. The [documentation for
`isImplicit`](https://github.com/llvm/llvm-project/blob/68a0d0c76223736351fd7c452bca3ba9d80ca342/clang/include/clang/AST/DeclBase.h#L596-L600)
does to some extent imply that implicit variables aren't written in
source.
This patch adds another condition to deciding whether a `VarDecl` should
be marked artificial. Specifically, don't treat structured bindings as
artificial.
**Main alternatives considered**
1. Don't use `isImplicit` in `CGDebugInfo` when determining whether to
add `DW_AT_artificial`. Instead use some other property of the AST that
would tell us whether a node was explicitly spelled out in source or not
* Considered using `SourceRange` or `SourceLocation` to tell us this,
but didn't find a good way to, e.g., correctly identify that the
implicit `this` parameter wasn't spelled out in source (as opposed to an
unnamed parameter in a function declaration)
2. We could've also added a bit to `VarDeclBitFields` that indicates
that a `VarDecl` is a holding var, but the use-case didn't feel like
good enough justification for this
3. Don't set the `VarDecl` introduced as part of a tuple-like
decomposition as implicit.
* This may affect AST matching/traversal and this specific use-case
wasn't enough to justify such a change
Fixes#48909
0 commit comments