[boost] "is-assignable" compile error using Boost 1.68 / LLVM-Clang / Windows

[Adam Hartshorne via Boost]

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'

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[degski via Boost]

On Wed, 19 Sep 2018 at 22:03, Adam Hartshorne via Boost <
bo...@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*

[Adam Hartshorne via Boost]

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

[Gavin Lambert via Boost]

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 <boost/type_traits/is_assignable.hpp> was not
included because __clang doesn't exist. Or something like that.

This usually doesn't happen when using MSVC or Clang directly, but since
you're using a hybrid the logic is confused.

[John Maddock via Boost]

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 <boost/type_traits/is_assignable.hpp> 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 <boost/type_traits/is_assignable.hpp>

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

[degski via Boost]

On Thu, 20 Sep 2018 at 10:41, John Maddock via Boost <bo...@lists.boost.org>
wrote:

> 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*

_______________________________________________

[Adam Hartshorne via Boost]

Thanks, that solved the issue.