[Bug c++/82745] Fails to warn on narrowing conversion by std::forward (e.g. when calling make_unique)

["helge at penne dot no" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #8 from helge at penne dot no ---
(In reply to Jonathan Wakely from comment #7)
> -Wsystem-headers is needed to get the warnings when the conversion happens
> in code inside a system-header (which is the case for lots of standard
> library templates).
> 
> See also PR 80472

Hmmm.  I will certainly give -Wsystem-headers a try as you suggest.  It will be
interesting to see how that turns out.  If our rather large code base compiles
cleanly with that option, then all is good, but if that results in warnings
inside headers and we cannot remove these through changes to our own code base,
then it is not really a viable solution.  -Werror is mandatory, I'm afraid.

I agree that it is very reasonable that the compiler is set up to disable
warnings from system headers like operating system include files, C-libraries
etc.  I have never tried compiling with -Wsystem-headers, but I expect to get a
large number of warnings from operating system headers and old libraries.

However, it could be argued that the STL is a little different.  Seen from the
outside, it does not seem impossible to engineer this to compile cleanly, even
with -Wall etc.  The STL is also different in that it not only provides
declarations of constants, data structures and functions.  It contains
templates that will generate code through their usage.  It could be argued that
it is just as important for this code to be correct as the code the the
developer writes manually, and that (at least some) compiler warnings should
therefore be issued for this code as well.

So perhaps the fundamental issue here is that it is a problem that -Wconversion
(and most likely many others) is suppressed inside the STL headers.

I suppose it might be possible to work around this by convincing the compiler
that our STL includes are not system headers, somehow.  Looking at the
libstdc++ source code, I see that they use "#pragma GCC system_header" in their
headers.  I assume that this is what defines them as system headers.  That will
make such a workaround difficult, unless we change libstdc++ outselves to
remove this.

I still believe that this is a problem that should be fixed.  However, changing
gcc to fix this is perhaps not the right approach as long as libstdc++ defines
itself as system headers using this pragma, and in that case perhaps this
defect report belongs with libstdc++, not gcc.