310a9f3f25
This patch is motivated by the debug-info issue in https://github.com/llvm/llvm-project/issues/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](0c4023ae3b/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](https://github.com/llvm/llvm-project/issues/48909#issuecomment-2238976579), but that is a confusing notion for debug-info, since these bindings *are* spelled out in source. The [documentation for `isImplicit`](68a0d0c762/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 https://github.com/llvm/llvm-project/issues/48909
2.2 KiB
2.2 KiB