https://github.com/ldionne commented:
High level comments and questions: IIUC, the goal here is for the compiler to be able to apply e.g. pointer authentication on fields of these structs automatically. It can't do so if they are standard layout types, because then users are technically allowed to poke into the binary representation of these types a bit too much. Did I get that right? Let's take for example `std::shared_ptr`. Before your patch, it is a standard layout class. However, users technically can't take advantage of that, because the only things that they would be allowed to do is inspect the common initial subsequence of `std::shared_ptr`, use `offsetof` with it, or cast a `std::shared_ptr<...>*` to its first member. None of that applies, because all of its members are private (and reserved names anyway). Hence, making it explicitly non-standard-layout should not be a breaking change for users. Do I follow your line of thinking correctly? Are there any other affordances provided by standard layout types that I would have missed? Either in terms of API (i.e. what users can do with a SL type), or ABI (e.g. the calling convention changes for SL types like it does for trivial types)? It's important to have a solid grasp of this before we can consider moving forward with this (and decide how to best do it). If this e.g. breaks the ABI in any way, we'll need to have a completely different conversation. Also, while we're talking about ABI, I assume that in your use case (which I perhaps naively imagine to be applying ptrauth to struct fields), I guess you'd be taking an ABI break to enable that new compiler feature, right? https://github.com/llvm/llvm-project/pull/151652 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
