From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D1513385800B; Wed, 2 Mar 2022 15:51:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D1513385800B From: "ldionne.2 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/33911] attribute deprecated vs. templates Date: Wed, 02 Mar 2022 15:51:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.3.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: ldionne.2 at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2022 15:51:31 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D33911 Louis Dionne changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ldionne.2 at gmail dot com --- Comment #21 from Louis Dionne --- (In reply to Martin Sebor from comment #20) > (In reply to Jonathan Wakely from comment #16) >=20 > Although Clang doesn't, warning for uses of a deprecated primary seems > correct/useful to me because there's no way to define a specialization of > the primary that's not deprecated. In your test case, there is no > specialization of b() that would not use some specialization of the prim= ary > class template, and since every specialization is a use of the primary, t= hat > would not be subject to its deprecated attribute. (It seems analogous to > warning for an unused constexpr function that can never be used in a core > constant expression.) I believe it is important to *not* diagnose when the template is never instantiated. Indeed, imagine a library is providing these declarations. It needs to keep them around for backwards compatibility, but it also wants to mark them as deprecated to make sure that no users actually use them. With the current state of affairs, GCC will issue a warning just because the declarations exist and are marked as deprecated, even if the user doesn't actually use these declarations. This is not useful behavior -- it ends up being so noisy that the only reasonable solution is to remove deprecation warnings altogether, which defeats the whole thing. This is exactly what we= 're hitting with libc++ on GCC right now. I think it would be worth reconsideri= ng the resolution of this issue to make GCC's behavior match Clang's behavior = more closely. > If you feel it's important to only warn for code that's instantiated, rat= her > than reopening this bug I suggest opening a separate bug just for that. See https://gcc.gnu.org/PR104760.=