From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116610 invoked by alias); 8 Dec 2018 18:05:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 116598 invoked by uid 89); 8 Dec 2018 18:05:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1713, merely, macros, concerns X-HELO: mail-ot1-f41.google.com Received: from mail-ot1-f41.google.com (HELO mail-ot1-f41.google.com) (209.85.210.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Dec 2018 18:05:48 +0000 Received: by mail-ot1-f41.google.com with SMTP id v23so6793527otk.9 for ; Sat, 08 Dec 2018 10:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LLajAJ4FGBkRbPIm2D+7SJL0Xd6pZ6Vkoke+lJRkX5A=; b=MOv1NsqoyuFP7880sEM2A4vMN37GWxYT/YZ3i6ztkcrUfI+Hl9r7j6exWyC6wocz8+ TUZsrF82mQCxxuLS/9C0hDGa4qTe5QMk1Ps4qbnhpHKtwADm7Is6wgvkaBKUZRn6z+9T 6kfu/QU98QeoIcPjLvJjq1gm7vr+2vWm+IrDAVpvfN6ZG3aS2/2KXl+na2ZFMfH1IDLm tQOl6MWgQ26qxWmGt7/nFRmZ+M+SKdY8b8bxgozfRYdwS543pkTc9IjhcKtLHwQIveOx 49xr0to3V7UmRihp7+3GpMC9zKGbA7w3uLZAnNTrJSoaFoYYl4MXSIqWpxSvZMJCd32d Y/3g== MIME-Version: 1.0 References: <20181208165817.GU12380@tucnak> In-Reply-To: From: Ville Voutilainen Date: Sat, 08 Dec 2018 18:05:00 -0000 Message-ID: Subject: Re: C++ PATCH for c++/88136, -Wdeprecated-copy too noisy To: Jason Merrill Cc: Jakub Jelinek , gcc-patches List Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-12/txt/msg00521.txt.bz2 On Sat, 8 Dec 2018 at 19:53, Jason Merrill wrote: > The documented policy for -Wall is, > > This enables all the warnings about constructions that some users > consider questionable, and that are easy to avoid (or modify to > prevent the warning), even in conjunction with macros. > ... > Note that some warning flags are not implied by '-Wall'. Some of > them warn about constructions that users generally do not consider > questionable, but which occasionally you might wish to check for; > others warn about constructions that are necessary or hard to avoid > in some cases, and there is no simple way to modify the code to > suppress the warning. > > It seems to me that this warning qualifies for -Wall under these > guidelines. Providing a copy constructor without a matching > assignment operator is definitely suspect; the false positive only > comes in because, as you say, there was no good reason to provide the > copy constructor for Private. And it's easy to avoid the warning by > declaring a defaulted assignment operator, if ABI concerns preclude > removing the constructor. > > New compiler releases will usually include new warnings that require > some code modification to accommodate. Why is this one particularly > problematic? I don't think it's any more problematic than any other warning that introduces new errors for fools that build with -Wall and -Werror. But considering that those errors are false positives, and that turning them off will in some cases require writing boiler-plate (defaulted assignments), I would merely prefer having another release round to get fixes for my codebase out in the wild.