[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707

--- Comment #2 from Mathias Stearn <redbeard0531 at gmail dot com> ---
Here is a boiled down example of some of our code that trips this warning:
https://godbolt.org/g/ChLrch. It also shows why we do this, since the codegen
is *substantially* better for init_table_memset than init_table_assignment, at
least at -O2. Even if you improve the codegen for that case tomorrow, we'd
still need to keep using memset for a while until we stop supporting older
compilers.

This is reduced from
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/document_internal.h.
The actual key type is stored as a variable-lenth string stored directly in the
buffer and the Key type in the interface is our pre-17 string_view equivalent.
The value is actually a type called Value, that holds an internal 16-byte type
called ValueStorage as its only member. ValueStorage also triggers the warning
in its lifetime methods:
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/value_internal.h#L165-L221
(the DEV macro expands to "if (DEBUG_BUILD)" so you can ignore anything on
those lines). If necessary I can try to boil down that type too, but it is much
more complex, so I'm not sure how small I can make it.

This is all to implement what is essentially a dynamically-typed JSON object
which is something we need to be *REALLY* fast. A lot of effort went into
micro-optimizing these types so that the business logic code doesn't need to
worry about any of this and can write very natural looking, modern c++ code.
All of this memory-munging is hidden in internal types in _internal.h files.
The user facing types are not supposed to expose any of this, except to the
implementations which are all friendly which each other.

The third_party code that is tripping this is in S2. It tries to memcpy
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/value_internal.h#L165-L221
an array of S2Points (typedef for Vector3<double>)
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/third_party/s2/util/math/vector3.h#L30.
This doesn't meet the self-or-friend condition described in the ticket, so I'm
not sure what the solution there is, but it is an example of code that is
correct (I think, I haven't reviewed it *too* closely) but still triggers this
warning.