[clang] [clang] Fix 71315698c9 in presence of incomplete types (PR #114095)

[Erich Keane via cfe-commits]

================
@@ -8900,7 +8900,8 @@ void Sema::CheckMemaccessArguments(const CallExpr *Call,
           << Call->getCallee()->getSourceRange());
     else if (const auto *RT = PointeeTy->getAs<RecordType>()) {
 
-      bool IsTriviallyCopyableCXXRecord =
+      bool MayBeTriviallyCopyableCXXRecord =
+          RT->isIncompleteType() ||
----------------
erichkeane wrote:

> According to https://godbolt.org/z/xcnb154de having fields that point to incomplete types does not make you non trivially copyable, so I'm not even sure it reduces the quality of the original warning.

Why WOULD it?  Those are pointers, which are complete types.

> So you're basically talking about this case:
> 
> ```
> struct S;
> 
> void foo(S *s1, S *s2) {
>   memcpy(s1, s2, 10);
> }
> 
> struct S {
>   S(const S&);
>   S& operator=(const S &);
> };
> ```
> 
> I'm not certain that's worth splitting off as its own diagnostic as `memcpy`, `memset`, etc all need you to pass in a size parameter and... anything the user puts there in case of an incomplete type is pretty suspect. Based on that, I think we may _want_ the diagnostic for incomplete types, but that the diagnostic only makes sense in C++ regardless of whether the type is complete or not.
> 
> However, GCC silences the diagnostic for incomplete types: https://godbolt.org/z/bsPnrKf19 so I may be missing some use case where this construct is safer than I'm thinking.

Yeah, something like that.  It ends up causing someone to be able to 'side-step' this diagnostic inadvertently by using an incomplete type.  So a separate warning of, "you're using an incomplete type here that might be non-trivially-copyable in the future ya know!" might be useful to some, though if we put it in the same group as this one, it might cause folks to throw the baby with the bath water.

More 'mulling' than having a request.  

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