[clang] Include [[clang::require_explicit_initialization]] warnings in system headers (PR #141133)

[Erich Keane via cfe-commits]

erichkeane wrote:

Here is where my mind is at:

1- We need, as a project to re-think/come up with a better way to figure out how to suppress warnings in header files.  I don't think there is a silver-bullet here, and no one has come up with a reasonable way forward on this.

2- I think the idea that 'warnings in the STL aren't actionable by users' is correct in SOME cases, but not all.  It is frustrating we don't have a way to figure out when an STL function is a 'proxy' for user action (like construct_at/invoke/emplace_back/ etc), where we should no longer suppress warnings in that instantiation-context.  PERHAPS we could find a way to mark it that way? 

3- This one somewhat scares me for things where the STL will need to 'invent' an object (eg, sees it is 'default constructible'/'trivially copyable', so does a default-construct + memcpy instead of a construct-in-place because reasons), which will result in false-positives, because as I said, the STL is 'assumed right'.

4- It is PROBABLY not a huge deal here, and is something we could perhaps use to fix 'later'.  This is an opt-in and perhaps a bit of a 'you get what you asked for' (even if you didn't know what you were asking for) via the attribute.  IMO, I wonder if we should INSTEAD start marking this diagnostic as an error?  It plays awkwardly with SFINAE IIRC, but we can mark it as SFINAE error anyway.

5- Even if we choose not to make it an error, I think I'm about 55/45 that we can accept this and hold our nose/push off the issues with figuring out STL proxy-function vs normal-function.  

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