From owner-freebsd-toolchain@freebsd.org Sat Jul 29 08:03:31 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA59ADBDB37 for ; Sat, 29 Jul 2017 08:03:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CF2696343E for ; Sat, 29 Jul 2017 08:03:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: by mailman.ysv.freebsd.org (Postfix) id CB69ADBDB36; Sat, 29 Jul 2017 08:03:31 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9474DBDB35 for ; Sat, 29 Jul 2017 08:03:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-86.reflexion.net [208.70.210.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8656F6343D for ; Sat, 29 Jul 2017 08:03:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13355 invoked from network); 29 Jul 2017 08:03:29 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Jul 2017 08:03:29 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 29 Jul 2017 04:03:29 -0400 (EDT) Received: (qmail 29609 invoked from network); 29 Jul 2017 07:34:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jul 2017 07:34:41 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id D185AEC8EFB; Sat, 29 Jul 2017 00:34:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build From: Mark Millard In-Reply-To: <20170729015914.184c2660@kalimero.tijl.coosemans.org> Date: Sat, 29 Jul 2017 00:34:39 -0700 Cc: Dimitry Andric , toolchain@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 08:03:32 -0000 On 2017-Jul-28, at 4:59 PM, Tijl Coosemans wrote: > On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric = wrote: >> On 28 Jul 2017, at 13:55, Tijl Coosemans wrote: >>>=20 >>> On Thu, 27 Jul 2017 21:42:01 +0000 pkg-fallout@FreeBSD.org wrote: =20= >> ... >>>> In file included from squirrel/squirrel/sqvm.cc:5: >>>> In file included from /usr/include/c++/v1/math.h:310: >>>> /usr/include/c++/v1/limits:149:85: error: expected expression >>>> _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() = _NOEXCEPT {return type();} >>>> = ^ >>>> squirrel/squirrel/sqobject.h:131:24: note: expanded from macro = 'type' >>>> #define type(obj) ((obj)._type) >>>> ^ =20 >>>=20 >>> Simutrans code defines 'type' as a macro. Shouldn't libc++ headers = use >>> _type or __type or something? =20 >>=20 >> No, the member name 'type' is used in many classes in the C++ = standard >> library, for example all the traits in . Programs = should >> not attempt to redefine this, at least not as a macro. >>=20 >> Note that this also doesn't work with libstdc++, e.g.: >>=20 >> $ cat boom.cpp >> #define type "nope, this will not work" >> #include >>=20 >> and then: >>=20 >> $ g++ -c boom.cpp >> boom.cpp:1:14: error: expected unqualified-id before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected class-name before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected '{' before string constant >> boom.cpp:1:14: error: expected class-name before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected '{' before string constant >> boom.cpp:1:14: error: expected class-name before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected '{' before string constant >> boom.cpp:1:14: error: expected class-name before string constant >> #define type "nope, this will not work" >> ^ >> boom.cpp:1:14: error: expected '{' before string constant >> boom.cpp:1:14: error: expected unqualified-id before string constant >> #define type "nope, this will not work" >> ^ >> In file included from boom.cpp:3:0: >> /usr/local/lib/gcc6/include/c++/type_traits:212:60: error: template = argument 1 is invalid >> : public __is_void_helper::type>::type >> ^ >> /usr/local/lib/gcc6/include/c++/type_traits:212:61: error: expected = '{' before '::' token >> : public __is_void_helper::type>::type >> ^~ >> [...and lots more errors like this...] >=20 > The code does not include or any of that C++11 stuff. = It > includes . This works with libstdc++ because it doesn't have > , but it would also work when was included, because > libstdc++ uses __type everywhere (and __enable_if and __is_arithmetic, > etc. where libc++ headers use enable_if and is_arithmetic). The > libstdc++ way makes more sense. You cannot expect C++98 code to know > about reserved identifiers in C++11 or C++11 code to know about = reserved > identifiers in later standards. I'll first note that Annex D D.5 C standard library headers says: "the C++ standard library provides the 25 C headers, as shown in table 154" and table 154 lists: . That is relevant for the below. ISO/IEC 14882:2011(E) 17.6.4.3.1 Macro Names says: "A translation unit that include a standard library header shall not #define or #undef names declared in any standard library header." I'll note that the standard has sections with titles like "Type names", "Class names", "Nested type names", "Names of template specializations", and "Predefined macro names". My understanding is that the earlier quote spans avoiding matching all such names. ISO/IEC 14882:2011(E) mandates such things as: template struct is_arithmetic; . . . template struct enable_if; . . . template typedef integral_constant { . . . typedef integral_constant type; . . . }; For targeting -std=3Dc++11 or later in compiles __enable_if and __is_arithemtic and __type would be wrong in these places and require code using the standard to use the names that have the __ prefixes, in violation of the standard's specifications. That includes having no explicit -std=3D but depending on a default that happens to end up with c++11 or later as the version to target. As I remember the standard makes few or no guarantees about avoiding implicitly getting more of the library header definitions than the #includes explicitly reference in the using code. Your wording fits better for identifiers that have no such mandated existence in any part of the library for the c++?? being targeted in the compile. (It is not the source code's intended target that directly matters: just the actual compile target.) The library identifiers that required under any version of the C++ standard are not C++ keywords under that standard. In a free-standing implementation the C++ keywords are a much higher percentage of the relevant names to avoid matching with macro names. Also it would seem a good idea to explicitly target the language version the code is designed for, such as using -std=3Dc++98 . Otherwise one needs to handle whatever the default version may be --and so handle being compatible with all official versions, not just the one for the original design/intent. Picking project-local macro names unlikely to match code that one does not control also seems to be a good idea. Some names are far more likely than others. "type" is rather generic. =3D=3D=3D Mark Millard markmi at dsl-only.net