"is-assignable" compile error using Boost 1.68 / LLVM-Clang / Windows
I receive the following build error when switching to LLVM toolset in VS2017 to build code using Boost 1.68. The code builds fine with MSVC compiler. 1>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 1>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'
On Wed, 19 Sep 2018 at 22:03, Adam Hartshorne via Boost < boost@lists.boost.org> wrote:
1>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 1>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'
You probably need to give information as to which library triggers this error, as has_trivial_move_assign.hpp is pulled in by almost all libraries and this "detection error" is upstream. There is (generally, but some libs have been fixed for this) a mismatch (deficiency) between the way clang-cl identifies it self (__clang__ **and** _MSCVER) and the way Boost libs try to identify the compiler used. So libraries that simply check for _MSCVER and then assume it's MSVC will show this problem, also checking in the wrong order can generate this problem. I've signaled this many times before, but this has always fallen on deaf ears. Also clang-cl is not in the test matrix, as Boost cannot be built in its entirety with clang-cl and only few people seem to think that there is any merit in trying to get that to work (even though Clang/LLVM provide for better tooling in every respect (also better binaries) and also allows for beginners to actually learn proper C++ as the warning messages (and hints) are actually discernible even for a beginner, contrary to the stuff that comes out of MSVC). These discussions usually end in a rant over the non-conforming MSVC-PP (which by now is conforming, but the one from VS-7.1 will keep on being broken and the focus seems to be on supporting that). degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
Looks like boost::variant is the problem.
2>In file included from C:\boost_1_68_0\boost/variant.hpp:17:
2>In file included from C:\boost_1_68_0\boost/variant/variant.hpp:51:
2>In file included from
C:\boost_1_68_0\boost/type_traits/is_nothrow_move_assignable.hpp:15:
2>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error
: no template named 'is_assignable'; did you mean 'std::is_assignable'?
2>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded
from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'
2>C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\VC\Tools\MSVC\14.13.26128\include\type_traits(768):
note: 'std::is_assignable' declared here
On Thu, Sep 20, 2018 at 4:35 AM degski
On Wed, 19 Sep 2018 at 22:03, Adam Hartshorne via Boost < boost@lists.boost.org> wrote:
1>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 1>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'
You probably need to give information as to which library triggers this error, as has_trivial_move_assign.hpp is pulled in by almost all libraries and this "detection error" is upstream.
There is (generally, but some libs have been fixed for this) a mismatch (deficiency) between the way clang-cl identifies it self (__clang__ **and** _MSCVER) and the way Boost libs try to identify the compiler used. So libraries that simply check for _MSCVER and then assume it's MSVC will show this problem, also checking in the wrong order can generate this problem.
I've signaled this many times before, but this has always fallen on deaf ears. Also clang-cl is not in the test matrix, as Boost cannot be built in its entirety with clang-cl and only few people seem to think that there is any merit in trying to get that to work (even though Clang/LLVM provide for better tooling in every respect (also better binaries) and also allows for beginners to actually learn proper C++ as the warning messages (and hints) are actually discernible even for a beginner, contrary to the stuff that comes out of MSVC).
These discussions usually end in a rant over the non-conforming MSVC-PP (which by now is conforming, but the one from VS-7.1 will keep on being broken and the focus seems to be on supporting that).
degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
On 20/09/2018 16:47, Adam Hartshorne wrote:
Looks like boost::variant is the problem.
No, those are just plain includes. Nothing to see there.
2>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 2>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'
The problem is actually here.
As degski suggests, it's probably a compiler detection quirk where the
BOOST_HAS_TRIVIAL_MOVE_ASSIGN macro has been defined because
__has_feature exists but
On 20/09/2018 06:40, Gavin Lambert via Boost wrote:
On 20/09/2018 16:47, Adam Hartshorne wrote:
Looks like boost::variant is the problem.
No, those are just plain includes. Nothing to see there.
2>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 2>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'
The problem is actually here.
As degski suggests, it's probably a compiler detection quirk where the BOOST_HAS_TRIVIAL_MOVE_ASSIGN macro has been defined because __has_feature exists but
was not included because __clang doesn't exist. Or something like that.
Just to be clear, it's a flat out bug in type_traits and has been fixed
for the next release (which doesn't help the OP), a workaround would be
to add:
#include
On Thu, 20 Sep 2018 at 10:41, John Maddock via Boost
Just to be clear, it's a flat out bug in type_traits and has been fixed for the next release ...
Thanks for clearing that up, it took a long time, but finally we got there then! Thanks to the person or persons who fixed it! degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
Thanks, that solved the issue. On Thu, Sep 20, 2018 at 8:41 AM John Maddock via Boost < boost@lists.boost.org> wrote:
On 20/09/2018 06:40, Gavin Lambert via Boost wrote:
On 20/09/2018 16:47, Adam Hartshorne wrote:
Looks like boost::variant is the problem.
No, those are just plain includes. Nothing to see there.
2>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 2>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'
The problem is actually here.
As degski suggests, it's probably a compiler detection quirk where the BOOST_HAS_TRIVIAL_MOVE_ASSIGN macro has been defined because __has_feature exists but
was not included because __clang doesn't exist. Or something like that. Just to be clear, it's a flat out bug in type_traits and has been fixed for the next release (which doesn't help the OP), a workaround would be to add:
#include
before any other boost includes in your program.
Best, John.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Adam Hartshorne -
degski -
Gavin Lambert -
John Maddock