paulkirth added a comment. I'm going to try to summarize an offline discussion w/ @mcgrathr about this here:
There are some other considerations to think about w.r.t. emitting names for non-source language constructs, as would be the case here. In fact, DWARF already handles this case: the "this" pointer in C++. Despite the fact that it may not be directly used in the source program, it is tagged as artificial, and gets a name, so that programmers can reference it within the debugger. Debuggers don't know anything special about C++, the compiler just emitted a DWARF variable that has the `DW_AT_name` of "this". They just reference the name, and allow users to access it as if it were another variable. The point is that the `DW_AT_name` has a special meaning to debuggers, which may be problematic if we try to emit a name when this isn't really a source level construct and isn't something that should be accessed like another variable. Generating a name for these items makes them addressable, and is //probably// more problematic for downstream consumers of DWARF than omitting the name. Generally, DWARF consumers probably shouldn't be relying on things like the name always being there. The standard is pretty clear that many fields are optional, i.e., they //may// be there or they //may not// be there. It's probably fine to gate the new DWARF items behind a compiler flag if there is concern about incompatible consumers. It could even be on by default, but at least it would be possible to opt out of the new behavior. You may even be able to gate it based on the DWARF version. That isn't strictly correct, but is offered as a possible pragmatic convenience on the rationale that concern about incompatible consumers probably applies to "old" consumers and consumers new enough to handle v5 could be assumed new/well-maintained enough to either already handle, or quickly be fixed to handle, nameless `DW_TAG_variable`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126224/new/ https://reviews.llvm.org/D126224 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
