Date: Sat, 29 Jul 2017 01:59:20 +0200 From: Tijl Coosemans <tijl@FreeBSD.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: toolchain@FreeBSD.org Subject: Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build Message-ID: <20170729015914.184c2660@kalimero.tijl.coosemans.org> In-Reply-To: <F47E0976-759A-45A0-8421-8FD4402A9980@FreeBSD.org> References: <201707272142.v6RLg1G4099900@beefy12.nyi.freebsd.org> <20170728135510.2c6de57f@kalimero.tijl.coosemans.org> <F47E0976-759A-45A0-8421-8FD4402A9980@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric <dim@FreeBSD.org> wrote:
> On 28 Jul 2017, at 13:55, Tijl Coosemans <tijl@freebsd.org> 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 <type_traits>. 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 <type_traits>
>
> 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<typename remove_cv<_Tp>::type>::type
> ^
> /usr/local/lib/gcc6/include/c++/type_traits:212:61: error: expected '{' before '::' token
> : public __is_void_helper<typename remove_cv<_Tp>::type>::type
> ^~
> [...and lots more errors like this...]
The code does not include <type_traits> or any of that C++11 stuff. It
includes <math.h>. This works with libstdc++ because it doesn't have
<math.h>, but it would also work when <cmath> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170729015914.184c2660>