[PATCH] D119051: Fix pod-packed functionality to use the C++11 definition of pod-ness

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D119051#3302125 <https://reviews.llvm.org/D119051#3302125>, @rnk wrote:

> Looks like the test fails on the Windows pre-merge bot: https://buildkite.com/llvm-project/premerge-checks/builds/77696#1836f181-a998-4695-b587-a832392222ea
>
> The debian bot seems to be failing for unrelated (clang tooling) reasons.

Ah, legit failure - should've caught that locally.

Seems I'm not really sure what POD rules GCC is using... https://godbolt.org/z/oczvTrdTM
My understanding is that this is C++03 non-POD, but C++11 POD:

  struct t1 {
  protected:
    int a;
  };

And this is also C++03 non-POD, but C++11 POD:

  struct t1 {
    t1() = default; // C++11 POD, <C++11 non-POD
    int a;
  };

Well, I guess, arguably, the second example has no definition in C++03, since it uses a C++11 feature, but we backport that as an extension. So perhaps our backport doesn't capture the POD-ness in the same way GCC does?

Because the original (`FieldClass->isPOD()`) classifies the first example as non-POD and the second example as POD, and the `isCXX11PODType` does the opposite, if I'm understanding the results of my program correctly. So I'm not sure what property to test for here to correctly model GCC's behavior. Perhaps I need to go and change Clang's definition for `FieldClass->isPOD()`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119051/new/

https://reviews.llvm.org/D119051