[Bug libstdc++/112318] New: Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[Bug libstdc++/112318] New: Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[enolan at alumni dot cmu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112318

            Bug ID: 112318
           Summary: Deprecated move ctor does not trigger
                    -Wdeprecated-declarations when creating a
                    std::optional
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: enolan at alumni dot cmu.edu
  Target Milestone: ---

When constructing a std::optional value for a type whose move ctor is marked
deprecated that invokes its move ctor, -Wdeprecated-declarations is not
triggered.

Compiler explorer link: https://godbolt.org/z/EPveeoEfn

Minimal reproduction:

#include <optional>

struct foo {
    foo() {}
    [[deprecated]] foo(foo&&);
};

void bar() {
    std::optional<foo> quux{foo{}};
}

> the exact version of gcc

g++ (GCC) 13.2.1 20231011 (Red Hat 13.2.1-4)

> the system type

Fedora release 38 (Thirty Eight)

> the options given when GCC was configured/built

Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.2.1-20231011/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1

> the complete command line that triggers the bug

g++ -c -Werror=deprecated-declarations poc.cpp

> the compiler output

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112318

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |c++

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-Wsystem-headers enables the warning. Front-end issue ...

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112318

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-10-31

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, the use of the deprecated function occurs in a system header, so it's
suppressed. There's not really anything libstdc++ can do here.

It seems to me that the front-end should consider the context where the
deprecated function is declared as well as where it's used. If the declaration
is not in a system header, then the use in a system header is probably a
template instantiation involving a user's type. In which case, it's not
"system" code, and should trigger the deprecated warning.

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112318

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
As this bug points out, we probably want to warn for any uses of deprecated
entities declared in user code, whether used in system headers or in user code.

And for something like std::auto_ptr which is declared in a system header, we
want to warn if it's used in user code.

So I think we should only suppress the warning when the declaration *and* the
use are both in system headers.

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[herring at lanl dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112318

S. Davis Herring <herring at lanl dot gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |herring at lanl dot gov

--- Comment #4 from S. Davis Herring <herring at lanl dot gov> ---
The issue is really broader than just "declaration or use is not in -isystem";
since it's standard practice to use -isystem for third-party headers (to avoid
"personal" warnings like -Wparentheses taking effect in code not written to
them), this still fails to issue a warning if `foo` comes from such a header. 
(But the warning works when foo's author checks for it in their own unit
tests...)

It's a very hard problem in general.  A colleague pointed me at Perl's carp,
which attempts to identify whose "fault" a diagnostic is
<https://perldoc.perl.org/Carp#DESCRIPTION>.  The package rule there could even
be applied to C++20 modules, or perhaps to top-level namespaces in a pinch. 
Beyond that, it might be worthwhile to presume that any warning triggered by a
type- or value-dependent expression should be associated (for -Wsystem-headers
purposes) with the point of instantiation, although I'm sure there would be
some false positives from that.  (There needs to be a better-than-#pragma way
to suppress individual deprecation warnings for such cases.)