dwblaikie 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? 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... https://github.com/llvm/llvm-project/pull/70639 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
