rsmith added a comment. In D72897#1825791 <https://reviews.llvm.org/D72897#1825791>, @rjmccall wrote:
> I know that Sema used to have a lot of issues with implicitly declaring > special members, but I also know that that was bound up with how we tracked > special state for the class, and that code has changed a lot. If you feel > that that's an unlikely problem now, and you're comfortable with potentially > having to generate implicit declarations of special members in different > orders to satisfy different ABIs, I can accept this approach. I'm not particularly overjoyed by having an ABI decision determined by the order in which Sema chooses to implicitly declare these members. I think it's unlikely to have stability problems (we explicitly force declaration of virtual implicit members at the end of the class before they can have been lazily declared), but avoiding a reliance on Sema's behavior would be nice. It'd be hard to avoid relying on `Sema` getting the order of implicit `operator==` functions right, though, as I don't think we want vtable layout to be responsible for figuring out the correspondence between implicit `operator==` functions and defaulted `operator<=>` functions. Please take a look at this alternative approach and see what you think. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72897/new/ https://reviews.llvm.org/D72897 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
