[lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[via cfe-commits]

avl-llvm wrote:

> > 2. always put DW_AT_const_value in DW_TAG_member.
> 
> My understanding is that this is not possible. Dependent initializer expressions can't be evaluated in all cases - we're only allowed to evaluate them in the places the language allows us to, otherwise we might produce the wrong answer.
> 
> For non-dependent initializer expressions I think we could produce the answer in all cases.
> 
> And if we want type descriptions that are consistent (valuable for use with Type Units, and with @avl-llvm's DWARFLinker work) and we want to include static member variables in those descriptions, then we could put the constant value in the declaration of the member in cases where the initializer is non-dependent. But we'd still have to put it out in a definition in the dependent cases (if we want consistency).
> 
> And if we have to put it out in a separate definition DIE anyway - probably good to do that consistently so there's fewer special cases?
> 
yep. Thanks. So it seems we have to drop DW_AT_const_value from DW_TAG_member if we would like to have consistent type descriptions.

> Admittedly there are other reasons type definitions are inconsistent (eg: implicit special members, nested types, and member function template specializations (& I guess static member variable template specializations)) - and we could move static variables out of the authoritative type definitions the same way we do for those cases. We can see this in type units (the type unit never has these entities in it, but the skeleton unit that references the type unit does have these features) - I'd expect something like that to be what @avl-llvm will want to do with DWARFLinker - though without type units in input, I'm not sure how easily it'll be to determine that those are the variant parts that shouldn't go in the canonical type definition...

Speaking for the other cases(It is probably out of the scoop of this patch) Are you saying that f.e. nested types or member function template specializations may look different in different compile units?

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