[cherry-pick][swift/release/5.10] [lldb] Check DW_AT_declaration to determine static data members

[Michael137]

Background

Prior to DWARFv4, there was no clear normative text on how to handle static data members. Non-normative text suggested that compilers should use DW_AT_external to mark static data members of structrues/unions. Clang does this consistently. However, GCC doesn't, e.g., when the structure/union is in an anonymous namespace (which is C++ standard conformant). Additionally, GCC never emits DW_AT_data_member_locations for union members (regardless of storage linkage and storage duration).

Since DWARFv5 (issue 161118.1), static data members get emitted as DW_TAG_variable.

LLDB used to differentiate between static and non-static members by checking the DW_AT_external flag and the absence of DW_AT_data_member_location. With
D18008 LLDB started to pretend that union members always have a 0 DW_AT_data_member_location by default (because GCC never emits these locations).

In D124409 LLDB stopped checking the DW_AT_external flag to account for the case where GCC doesn't emit the flag for types in anonymous namespaces; instead we only check for presence of DW_AT_data_member_locations.

The combination of these changes then meant that LLDB would never correctly detect that a union has static data members.

Solution

Instead of unconditionally initializing the member_byte_offset to 0 specifically for union members, this patch proposes to check for both the absence of DW_AT_data_member_location and DW_AT_declaration, which consistently gets emitted for static data members on GCC and Clang.

We initialize the member_byte_offset to 0 anyway if we determine it wasn't a static. So removing the special case for unions makes this code simpler to reason about.

Long-term, we should just use DWARFv5's new representation for static data members.

(cherry picked from commit f74aaca)

[Michael137]

@swift-ci test