[DWARFLinkerParallel] Fix member initialization order

[MaskRay]

DWARFLinkerImpl::DWARFLinkerImpl initializes
DebugStrStrings/DebugLineStrStrings/CommonSections using GlobalData
but GlobalData is initialized after the three members.
Move GlobalData before.

Fix #81110

[dwblaikie]

I was concerned there might be missing test coverage here - but looks like the issue is benign (apart from the GCC warning itself) as the member is only stored as a reference and not used until after it's constructed.

Looking at Clang and GCC's behavior for the warning:

https://godbolt.org/z/G7ndsTv5c

It looks like GCC might have some quirks (it only warns about this case (escaping a reference to a member before the member is initialized) by the looks of it, if the ctor has only 1 parameter?).

Perhaps we should disable GCC's warning and rely on Clang's more conservative interpretation?

(though I don't actually object to this particular change - I think it's clearer/less subtle/etc - but in terms of what's worth filing bugs, etc about)

[MaskRay]

I was concerned there might be missing test coverage here - but looks like the issue is benign (apart from the GCC warning itself) as the member is only stored as a reference and not used until after it's constructed.

Looking at Clang and GCC's behavior for the warning:

godbolt.org/z/G7ndsTv5c

It looks like GCC might have some quirks (it only warns about this case (escaping a reference to a member before the member is initialized) by the looks of it, if the ctor has only 1 parameter?).

Perhaps we should disable GCC's warning and rely on Clang's more conservative interpretation?

(though I don't actually object to this particular change - I think it's clearer/less subtle/etc - but in terms of what's worth filing bugs, etc about)

Interesting. I did not realize that there's a clang-vs-GCC difference and the Clang behavior suppressing the diagnostic for a reference is intentional (seems around 2014).
(It seems that Clang's conservative behavior misses certain cases, e.g.

llvm-project/clang/test/SemaCXX/constructor-initializer.cpp

Line 159 in 2ed0aac

: A(IntWrapper(A)), // Due to a conservative implementation, we do not report warnings inside function/ctor calls even though it is possible to do so.

)

Suppressing -Wuninitialized for GCC sounds good.

Filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987 ("Binding a reference to an uninitialized data member should not cause -Wuninitialized")