[llvm] [DebugInfo] Add support for emitting DW_AT_defaulted (PR #213187)

[Alex Langford via llvm-commits]

bulbazord wrote:

> > > (The last one major one of these for context was about the packed attribute and whether clang should take lldbs word for it that the layout/field offsets were correct even if clang wouldn'tve computed matching offsets given the class description- and we did manage to relax clangs requirements and not add the packed attribute to the dwarf just to redundantly encode/justify the data that was already correctly encoded in the layout provided by dwarf)
> > 
> > 
> > Ah, in this case, clang produced one AST ahead of time in the form of a PCM and LLDB is creating an AST from DWARF. They do not agree (and cannot ever agree as-is). This concerns `defaulted` special member functions which have ABI implications. I'm not sure if clang should be tolerant of this particular difference.
> 
> Is the function code generated in the binary being debugged? Then we do know the Abi from the debug info perhaps? (Though the debug info doesn't really encode the abi... & Perhaps should, though it at least encodes enough info for callers)
> 
> If you're talking about the Abi impact in terms of whether the type is trivially copyable or not - that is encoded in the dwarf & clang should trust that and not try to recompute the property or care about some contradiction (same argument as for the packed layout)

This is where things get a little fuzzy for me. I'm shepherding this change, but I'm still relatively new to working on DebugInfo and clang, so I should probably ask more questions before making any more (potentially foolish) assertions 😅. I'd like to understand your idea more about clang being more tolerant to AST Input. The specific failure case here is that clang is diagnosing an ODR mismatch because the ASTs differ. Would relaxing the ODR logic be considered acceptable here? Or did you have something else in mind? I'm not sure how the packed attribute would translate to this scenario.

@vsapsai Perhaps you can chime in? You diagnosed the original failure.

https://github.com/llvm/llvm-project/pull/213187