https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
Louis Dionne <ldionne.2 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ldionne.2 at gmail dot com
--- Comment #21 from Louis Dionne <ldionne.2 at gmail dot com> ---
(In reply to Martin Sebor from comment #20)
> (In reply to Jonathan Wakely from comment #16)
>
> 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 primary
> class template, and since every specialization is a use of the primary, that
> 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 reconsidering
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, rather
> than reopening this bug I suggest opening a separate bug just for that.
See https://gcc.gnu.org/PR104760.
