Consider code like this: struct X { protected: ~X() {} }; struct Y : X { Y() = default; Y(const Y& other) : X(other) {} }; int main() { Y y; Y y2 = y; } gcc 9 warns about it, because X has a user-provided destructor. However, in this particular case, and in cases where the implicitly-defaulted copy/move are fine but the destructor does some extra work and is thus user-provided, the compiler will warn. The warning completely shatters the ability to build Qt.
We've been there before with -Wexpansion-to-defined though.
This is not just a Qt problem. I will write a proposal to undeprecate this deprecation for C++20 before the next committee meeting.
(In reply to Richard Biener from comment #1) > We've been there before with -Wexpansion-to-defined though. That's only in -Wextra and -Wpedantic, though, not -Wall, so it's not exactly the same.
Author: jason Date: Thu Dec 6 21:17:08 2018 New Revision: 266867 URL: https://gcc.gnu.org/viewcvs?rev=266867&root=gcc&view=rev Log: PR c++/88136 - -Wdeprecated-copy false positives Deprecating the copy operations because the class has a user-provided destructor turns out to have too many false positives; this patch adjusts -Wdeprecated-copy to only deprecate if the other copy operation is user-provided. To get the earlier behavior, people can explicitly request it with -Wdeprecated-copy-dtor. gcc/c-family/ * c.opt (Wdeprecated-copy-dtor): New. (Wdeprecated-copy): Move to -Wextra. gcc/cp/ * class.c (classtype_has_depr_implicit_copy): Rename from classtype_has_user_copy_or_dtor. * method.c (lazily_declare_fn): Adjust. * decl2.c (cp_warn_deprecated_use): Refer to -Wdeprecated-copy-dtor if deprecation is due to a destructor. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/method.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.dg/cpp0x/depr-copy1.C
(In reply to Jason Merrill from comment #4) > Author: jason > Date: Thu Dec 6 21:17:08 2018 > New Revision: 266867 > > URL: https://gcc.gnu.org/viewcvs?rev=266867&root=gcc&view=rev > Log: > PR c++/88136 - -Wdeprecated-copy false positives > > Deprecating the copy operations because the class has a user-provided > destructor turns out to have too many false positives; this patch adjusts > -Wdeprecated-copy to only deprecate if the other copy operation is > user-provided. To get the earlier behavior, people can explicitly request > it with -Wdeprecated-copy-dtor. > > gcc/c-family/ > * c.opt (Wdeprecated-copy-dtor): New. > (Wdeprecated-copy): Move to -Wextra. > gcc/cp/ > * class.c (classtype_has_depr_implicit_copy): Rename from > classtype_has_user_copy_or_dtor. > * method.c (lazily_declare_fn): Adjust. > * decl2.c (cp_warn_deprecated_use): Refer to -Wdeprecated-copy-dtor > if deprecation is due to a destructor. > > Modified: > trunk/gcc/c-family/ChangeLog > trunk/gcc/c-family/c.opt > trunk/gcc/cp/ChangeLog > trunk/gcc/cp/class.c > trunk/gcc/cp/cp-tree.h > trunk/gcc/cp/decl2.c > trunk/gcc/cp/method.c > trunk/gcc/doc/invoke.texi > trunk/gcc/testsuite/g++.dg/cpp0x/depr-copy1.C so... FIXED now?
Any chance of moving this warning out of -Wextra and re-considering adding it there for GCC 10?
Innocent users are going to hit it: https://bugreports.qt.io/browse/QTBUG-75210
Indeed this will be hit even when the own code has no issue, but qt headers are included. See also https://github.com/bitcoin/bitcoin/issues/15822
(In reply to Ville Voutilainen from comment #2) > This is not just a Qt problem. I will write a proposal to undeprecate this > deprecation for C++20 before the next committee meeting. Can you give a link to that proposal?
I don't think it has been written yet.
(In reply to Jonathan Wakely from comment #10) > I don't think it has been written yet. Right; I decided against it, since the cats are out of the bag and shipping implementations voted with their feet, so Rule of Five is now the law of the land, as far as I care.
Could GCC folks subscribed to this thread take a look on false-positive report (bug 92145) and not working suppression pragma (bug 94492) for this warning, please?
So let's call this fixed.