From owner-freebsd-toolchain@freebsd.org Sat Jul 29 19:27:13 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 329FFDC98E2 for ; Sat, 29 Jul 2017 19:27:13 +0000 (UTC) (envelope-from tijl@freebsd.org) 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 022377536C for ; Sat, 29 Jul 2017 19:27:13 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id F2B51DC98E1; Sat, 29 Jul 2017 19:27:12 +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 F2449DC98E0 for ; Sat, 29 Jul 2017 19:27:12 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay119.isp.belgacom.be (mailrelay119.isp.belgacom.be [195.238.20.146]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3561775358; Sat, 29 Jul 2017 19:27:11 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3AeGZxqR1x6/71t8s1smDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seITI/ad9pjvdHbS+e9qxAeQG96Ku7Qc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q89pDXYAhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWRPUMZPWSJcAY2z?= =?us-ascii?q?bYUPAOUdMuhXtIT9u1kDoQeiCQWwGO/j1DlFjWL2060g1OQhFBnL0hIhH9IMtH?= =?us-ascii?q?Tfscv4NKAVUeCu0qbIyC/Mb/VN2Tzg74XIbhEhofOIXb9rccTR01cgGB3Yg1uN?= =?us-ascii?q?p4LpJTSV1v4Cs2WC6edrSOyhi2kiqw5rozivwN8hiofTho0L1F/L7j55z5svKd?= =?us-ascii?q?2/Uk57btipG4ZTuSGCL4Z7Qd4uT3t2tCs1yrAKo4O3cSoOxZg92hLSaeCLfo6V?= =?us-ascii?q?6Rz5TumROy13hHd9dbK6gBa97Favx/XnVsmxzFZKti1FksTQtnwV1xzc9MyHSv?= =?us-ascii?q?xl80eiwzmP0wHT6uRaLkAukqrXMYIhwr8ylpoXq0jMAij2mELtjKCIc0Ur4O6o?= =?us-ascii?q?6//9brXhvJ+cOJd4igD4MqswhsyyGec1PhUUU2SF9umx1Kfv8VD7TbhOlPE6j6?= =?us-ascii?q?vUvIzCKcQevKG5AgtV0og56xa4CjeryMgYnXgFLFJBYx+HgZLpNE/QL//jFvew?= =?us-ascii?q?nk6gkDBxx/DJJrHhGInCLmDfkLf9erZw81JcyA00zdBb+51UCqsOIPP1WkLqut?= =?us-ascii?q?zYFAE2PBKvzOb8FdpxzIQeWXiAAqWBKqPdrUeI5v4zI+mLfIIapTf9K/0+6v7g?= =?us-ascii?q?l382h0EScrKy3ZQKcny4Ge5mI0rKKUbr1/IIC2RCmws6SOXwhBXWVDdJZHOzd6?= =?us-ascii?q?4n4nQ8Doa3S4HOWtb+rqaG2XKHH59SLktBDUuBFH7ubM3QR/YObAq8OMJsuAco?= =?us-ascii?q?E7+7RNlyhlmVqAbmxu8/faLv8SoCuMemjYAt6g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DOBQDK4HxZ/6qz9VFcGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgy9EEBBtJ48AjwYBgWstAZdvJIF?= =?us-ascii?q?Yg0sCg3NDFQEBAQEBAQEBAQEBaihCDoFjJAGCQAEBAQECATocIwULCxgJJQ8qH?= =?us-ascii?q?gYTiicMsy2LPAEBAQEBAQEDAQEBAQEjgyiIITSKaAWJYYcKgWKNIodPg0wFiHp?= =?us-ascii?q?8gXSPWpVyNSKBClMxCIVfHBmBUD42gxWHGgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2DOBQDK4HxZ/6qz9VFcGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBgy9EEBBtJ48AjwYBgWstAZdvJIFYg0sCg3NDFQEBA?= =?us-ascii?q?QEBAQEBAQEBaihCDoFjJAGCQAEBAQECATocIwULCxgJJQ8qHgYTiicMsy2LPAE?= =?us-ascii?q?BAQEBAQEDAQEBAQEjgyiIITSKaAWJYYcKgWKNIodPg0wFiHp8gXSPWpVyNSKBC?= =?us-ascii?q?lMxCIVfHBmBUD42gxWHGgEBAQ?= Received: from 170.179-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.245.179.170]) by relay.skynet.be with ESMTP; 29 Jul 2017 21:27:08 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v6TJR7rC004327; Sat, 29 Jul 2017 21:27:08 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sat, 29 Jul 2017 21:27:06 +0200 From: Tijl Coosemans To: Mark Millard Cc: Dimitry Andric , toolchain@FreeBSD.org Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Message-ID: <20170729212706.33841c4c@kalimero.tijl.coosemans.org> In-Reply-To: References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <20170729015914.184c2660@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 19:27:13 -0000 On Sat, 29 Jul 2017 00:34:39 -0700 Mark Millard wrote: > 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: >>>> >>>> On Thu, 27 Jul 2017 21:42:01 +0000 pkg-fallout@FreeBSD.org wrote: >>> ... >>>>> 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) >>>>> ^ >>>> >>>> Simutrans code defines 'type' as a macro. Shouldn't libc++ headers use >>>> _type or __type or something? >>> >>> 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. >>> >>> Note that this also doesn't work with libstdc++, e.g.: >>> >>> $ cat boom.cpp >>> #define type "nope, this will not work" >>> #include >>> >>> and then: >>> >>> $ 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...] >> >> 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; > . . . > }; But none of this should be exposed to C++98 code. These names were not reserved in the C++98 standard so C++98 code is free to use them. If libc++ cannot compile such valid C++98 code it is simply not compliant with that standard. Note that in this case we were lucky to see a diagnostic. C++98 code may use these names in a way that doesn't cause an error. Who's going to review our 27000 ports to make sure they are still compiled correctly? > For targeting -std=c++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= but depending on a > default that happens to end up with c++11 or > later as the version to target. Of course things like __enable_if are for internal use only. In C++11 mode enable_if needs to be made available.