From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 149683858D3C; Fri,  2 Jun 2023 14:45:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 149683858D3C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1685717103;
	bh=zYh3cNdZ+nyFPvBmh5MgP79I7TDbfU20XtaQzMxZHEo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=VIAtChFN0h+pPXrlsLbq/RGqsPOwu2qPMeYFcERL1jDpZzmXQkFTik87GkMflE8Q5
	 krhic+8ltHMrG0Fi1L50qMqWfuib2udDCv5o25rkQ4Cryh4GjTcpzScohY31qb9jYc
	 DP/m5nPueQbZVLBpXuk0zygZCK66NopZRU+YjmCY=
From: "piotrwn1 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/110092] Missing warning that internal header is used
Date: Fri, 02 Jun 2023 14:45:02 +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: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: piotrwn1 at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
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: 
Message-ID: <bug-110092-4-7Zi6JZ8fu0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110092-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110092-4@http.gcc.gnu.org/bugzilla/>
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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #3 from Piotr Nycz <piotrwn1 at gmail dot com> ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Piotr Nycz from comment #0)
> > So, probably it is doable to add warning like: "bist/shared_ptr.h is an
> > internal header file, included by other library headers. Do not attempt=
 to
> > use it directly. Use <memory> instead"
>=20
> We could add this to <bits/shared_ptr.h>:
>=20
> #ifndef _GLIBCXX_MEMORY
> # error Do not include <bits/shared_ptr.h> directly, include <memory>
> instead.
> #endif
>=20
> But then you'd get an error when you include <regex>, or <filesystem>, or
> <chrono>, or any of the other headers that use std::shared_ptr internally.
>=20
> So we'd have to do:
>=20
> #if !defined _GLIBCXX_MEMORY && !defined _GLIBCXX_CHRONO && !defined
> _GLIBCXX_REGEX \
>     && ! defined ...
>=20
> And that would be a pain to maintain.
>=20
> And then it would still not give an error for this, even though it's still
> wrong:
>=20
> #include <chrono>
> #include <bits/shared_ptr.h>
> std::shared_ptr<int> p;
>=20
> So I don't think this can really be solved in the compiler without a lot =
of
> work to hardcode special handling for each of those headers.

Well, I did not mean to make such a mess in compiler headers for sure. But =
if
it is somehow detectable that the compiler is compiling something in user
directories (not in std library, compiler stuff) then maybe it can be detec=
ted
by compiler that something internal is included in user file. I am just
guessing, I do not have any knowledge about how gcc compiler is working.=20
I see that system headers have some pragma telling it is system header and
these internal headers have comment in `@file` section that it is internal.=
=20

But of course - it could be done by some other tool like clang-tidy, if thi=
s is
a big problem. I just think it would be nice to have such warning - so it is
more "new feature request" than bug report.=