[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