[libcxx-commits] [PATCH] D121213: [libc++] Enable modernize-use-equals-delete

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Thu Mar 16 08:52:44 PDT 2023


ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: mikhail.ramalho.

I just looked at everything again with the understanding that adding a *copy* assignment operator doesn't have any impact on the generation of a copy constructor by the compiler (which frankly is bonkers), and I think this patch is correct without a doubt. The rules are just crazy though.

Can you rebase this onto `main`, make sure the CI is green and ship this? Please ping me again if you need to add any additional `= delete`s to this patch, I'll want to look again. This is kinda subtle and has the potential for a super subtle ABI break if gotten wrong.



================
Comment at: libcxx/include/__bit_reference:159
 
+    __bit_const_reference& operator=(const __bit_const_reference&) = delete;
+
----------------
ldionne wrote:
> I'm not sure about this one, see question.
Since this only touches `operator=`, this can't affect TFPC-ness.


================
Comment at: libcxx/include/map:692
 
+    __map_node_destructor& operator=(const __map_node_destructor&) = delete;
+
----------------
ldionne wrote:
> I'm not sure about this one. I think it was TFPC before the patch, because there were no copy/move ctors declared.
> 
> After the patch, there shouldn't be any copy/move ctor declared unless the compiler declares them as deleted, in which case it would become non-TFPC.
Since this only touches `operator=`, this can't affect TFPC-ness.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121213



More information about the libcxx-commits mailing list