From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050:0:465::201]) by sourceware.org (Postfix) with ESMTPS id 61A953858C52; Wed, 16 Aug 2023 13:19:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 61A953858C52 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=aarsen.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aarsen.me Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4RQpdL56rvz9ssn; Wed, 16 Aug 2023 15:19:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1692191974; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dx0rb2Ks05ZXVxqAQdcnZjdiGiAJxDi4ibTCLmbImd8=; b=pOvuflfj5QcXH01D700KQxAMi3KjWgLiunV1/oIuEzURIpn6J2cmFusTz9fSgiGrGj71rt y3CgUcYkKYEmt41B4rCIMd2OyWCtbxN+YnJhpoE7wAlZPeeYlFIfUV40vZwnEkdJq98Zr4 cQiX2wnaoRzjU2xS2dOO3IggxlIV/PHSWvrrbKmpZ0jx/iRzbGiCgJ1FzSYny3kHXk0qQ+ U05BYS0Zptgi4SP1yxCv0tfhNdXpUlMVZXnqHmIcrdum+BcB1cUejX55Div3Yu8q+kddQT K5bvZjC47g+ehquULBAtEXvPp2PUzG2q2fFiMv8Oa1NnOG3XhgCkzWZLVXeZpQ== References: <20230813195939.1099991-1-arsen@aarsen.me> <20230813195939.1099991-2-arsen@aarsen.me> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Jonathan Wakely Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH v2 2/2] libstdc++: Replace all manual FTM definitions and use Date: Wed, 16 Aug 2023 14:47:12 +0200 In-reply-to: Message-ID: <86jztvcefw.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jonathan Wakely writes: > [..snip..] > Thanks for adding the comments like "// C++ < 20". > > I think in the comment on the #endif can be just __cpp_lib_any > rather than defined(__cpp_lib_any). Similarly for > __cpp_lib_atomic_float in . Oh, and __cpp_lib_atomic_ref. And > in , and several others. I think I'd like those to be > consistent, and usually we just name the macro in the #endif comment, > sometimes abbreviated for clarity, without the explicit defined(...). ACK. Fixed all of those. > For this error in please add <> around "version" and remove > the question mark: > +# error "libstdc++ bug: no lock-free atomics but they were emitted in ve= rsion?" > > Similarly, please remove the question marks from the two #errors in > : > +# error "libstdc++ bug: is_corresponding_member and > is_layout_compatible are provided but their FTM is not set?" > +# error "libstdc++ bug: is_pointer_interconvertible available but FTM u= nset?" > > In you have: > +# error "libstdc++ bug: string_contents not defined when it should be" > That should be contains, not contents. > > OK for trunk with the #error changes. The #endif cleanup can be > fixed in a follow-up. >=20 > It seems like there's some inconsistency (probably some preexisting) > about whether you use: > #if __cpp_lib_xxx > or > #ifdef __cpp_lib_xxx > That can be tidied up later. > > Currently we define many of the macros in the "bits" headers, e.g. in > bits/stl_iterator.h > > +#define __glibcxx_want_constexpr_iterator > +#define __glibcxx_want_array_constexpr > +#define __glibcxx_want_make_reverse_iterator > +#define __glibcxx_want_move_iterator_concept > +#include > > We should consider only defining those in itself. So that > when other parts of the lib include bits/stl_iterator.h they don't > define the macros. That would mean that > __cpp_lib_make_reverse_iterator is not defined by and > , for example. Even though they do actually provide the > features, the macro would only be defined by and . > This might encourage users to include the right headers, instead of > relying on transitive includes. > If we do that, our own internal checks for features would all need to use: > #if __glibcxx_make_reverse_iterator > because they wouldn't have the __cpp_lib_xxx macro, because they only > include the internal bits header not . > > That's for another day though. Yes, that sounds quite reasonable. I like the idea that headers should export narrower FTMs. Pushed. Thanks :-) =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZNzM5F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTFooA+QHfPROuEH1A2CJM6/fwLThMKaDw4GRESDa4 /9srMyThAQCAOXTKk4gOEFGGEcchd5Pu3C6WlR8O1UBJ1vj0qIDbAQ== =F68O -----END PGP SIGNATURE----- --=-=-=--