mu @1.6.3: error: no matching constructor for initialization of 'value_type' (aka 'pair<const std::__1::basic_string<char>, Container>')

[ryandesign (Ryan Carsten Schmidt)]

mu fails to build on ​Yosemite and ​El Capitan using Xcode clang:

In file included from mu-query-threads.cc:20:
In file included from ./mu-query-threads.hh:23:
In file included from ./mu-query-results.hh:34:
In file included from /opt/local/include/xapian.h:77:
In file included from /opt/local/include/xapian/matchspy.h:36:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/map:634:11: error: no matching constructor for initialization of 'value_type' (aka 'pair<const std::__1::basic_string<char>, Container>')
        : __cc(std::forward<_Args>(__args)...) {}
          ^    ~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:1740:31: note: in instantiation of function template specialization 'std::__1::__value_type<std::__1::basic_string<char>, Container>::__value_type<const std::__1::basic_string<char> &, Mu::QueryMatch &>' requested here
            ::new((void*)__p) _Up(_VSTD::forward<_Args>(__args)...);
                              ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:1656:18: note: in instantiation of function template specialization 'std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char>, Container>, void *> >::construct<std::__1::__value_type<std::__1::basic_string<char>, Container>, const std::__1::basic_string<char> &, Mu::QueryMatch &>' requested here
            {__a.construct(__p, _VSTD::forward<_Args>(__args)...);}
                 ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:1502:14: note: in instantiation of function template specialization 'std::__1::allocator_traits<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char>, Container>, void *> > >::__construct<std::__1::__value_type<std::__1::basic_string<char>, Container>, const std::__1::basic_string<char> &, Mu::QueryMatch &>' requested here
            {__construct(__has_construct<allocator_type, _Tp*, _Args...>(),
             ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/map:2140:20: note: in instantiation of function template specialization 'std::__1::allocator_traits<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char>, Container>, void *> > >::construct<std::__1::__value_type<std::__1::basic_string<char>, Container>, const std::__1::basic_string<char> &, Mu::QueryMatch &>' requested here
    __node_traits::construct(__na, _VSTD::addressof(__h->__value_),
                   ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/map:2158:25: note: in instantiation of function template specialization 'std::__1::multimap<std::__1::basic_string<char>, Container, std::__1::less<std::__1::basic_string<char> >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char>, Container> > >::__construct_node<const std::__1::basic_string<char> &, Mu::QueryMatch &>' requested here
    __node_holder __h = __construct_node(_VSTD::forward<_Args>(__args)...);
                        ^
mu-query-threads.cc:159:30: note: in instantiation of function template specialization 'std::__1::multimap<std::__1::basic_string<char>, Container, std::__1::less<std::__1::basic_string<char> >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char>, Container> > >::emplace<const std::__1::basic_string<char> &, Mu::QueryMatch &>' requested here
                        dups.emplace(msgid, mi.query_match());
                             ^
mu-query-threads.cc:571:23: note: in instantiation of function template specialization 'determine_id_table<Mu::QueryResults>' requested here
        auto id_table{determine_id_table(qres)};
                      ^
mu-query-threads.cc:604:9: note: in instantiation of function template specialization 'calculate_threads_real<Mu::QueryResults>' requested here
        calculate_threads_real(qres, descending);
        ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:273:5: note: candidate constructor not viable: no known conversion from 'Mu::QueryMatch' to 'const Container' for 2nd argument
    pair(const _T1& __x, const _T2& __y)
    ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:278:9: note: candidate template ignored: could not match 'pair' against 'basic_string'
        pair(const pair<_U1, _U2>& __p
        ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:313:42: note: candidate template ignored: disabled by 'enable_if' [with _U1 = const std::__1::basic_string<char> &, _U2 = Mu::QueryMatch &]
              class = typename enable_if<is_convertible<_U1, first_type>::value &&
                                         ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:323:9: note: candidate template ignored: could not match 'pair' against 'basic_string'
        pair(pair<_U1, _U2>&& __p,
        ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:270:49: note: candidate constructor template not viable: requires 0 arguments, but 2 were provided
    _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR pair() : first(), second() {}
                                                ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:357:9: note: candidate constructor template not viable: requires single argument '__p', but 2 arguments were provided
        pair(_Tuple&& __p)
        ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:368:9: note: candidate constructor template not viable: requires 3 arguments, but 2 were provided
        pair(piecewise_construct_t __pc, tuple<_Args1...> __first_args,
        ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:405:9: note: candidate constructor template not viable: requires 5 arguments, but 2 were provided
        pair(piecewise_construct_t,
        ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:288:5: note: candidate constructor not viable: requires single argument '__p', but 2 arguments were provided
    pair(const pair& __p) = default;
    ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/utility:331:5: note: candidate constructor not viable: requires single argument '__p', but 2 arguments were provided
    pair(pair&& __p) = default;
    ^

It succeeds on Sierra and later using Xcode clang, and it succeeds on Mavericks and earlier using newer MacPorts clang. So the simplest fix would be to blacklist older clangs. Perhaps (a guess):

compiler.blacklist {clang < 900}

Plus at the top:

PortGroup compiler_blacklist_versions 1.0

[ra1nb0w]

thank you ryan.

I thought that compiler.cxx_standard 2014 was enough to blacklist not valid compilers. Blacklisted clang < 900 since should be sufficient to avoid the error.

Can you restart the build? thank you.

[Davide Gerhard <ra1nb0w@…>]

In f4a6cde880c6fa5dd44fbab8f6f7d387d7d1b220/macports-ports (master):

mu: fix build on macos =< 10.11

Closes: #63364

[ryandesign (Ryan Carsten Schmidt)]

Replying to ra1nb0w:

I thought that compiler.cxx_standard 2014 was enough to blacklist not valid compilers. Blacklisted clang < 900 since should be sufficient to avoid the error.

compiler.cxx_standard 2014 will select only C++14-compatible compilers, based on MacPorts base's understanding of which compilers are C++14-compatible. Either MacPorts base's understanding is wrong, or this project requires C++14 and also something else that is not in the earliest C++14-compatible compilers.

Can you restart the build? thank you.

Whenever you commit a change to a port, any necessary builds will be scheduled on the buildbot automatically.

[ra1nb0w]

still fails on 10.10 and 10.11 (these only). I write to upstream. For reference ​https://github.com/djcb/mu/issues/2086

[ryandesign (Ryan Carsten Schmidt)]

Replying to ra1nb0w:

still fails on 10.10 and 10.11 (these only).

No, after your change, it succeeded on both.

• ​https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/152314
• ​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/150944

If you were basing your diagnosis on ​https://ports.macports.org/port/mu/details/, note that the ports web site does not update instantly. It polls the buildbot for new build information periodically. If you want the latest information before the ports web site has retrieved it from buildbot, look directly on the buildbot e.g. ​https://build.macports.org/waterfall.

[ra1nb0w]

Ooooo, I used ports.macports.org :)

thank you!

[kencu (Ken)]

c++ feature support in compilers is more of a curve of implementation rather than a square wave:

​https://clang.llvm.org/cxx_status.html

MacPorts sets the bar for standard support at a reasonable level. If set too high, many ports that build fine with the system clang would needlessly call in a macports-clang for the build.

Some features of c++17 and c++20 are still unimplemented by clang.

and Apple's clang versions are of course related to but not directly translatable to the oss clang versions...

[ra1nb0w]

thank you very much kencu for the clarification!

have a great weekend

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

c++ feature support in compilers is more of a curve of implementation rather than a square wave:

​https://clang.llvm.org/cxx_status.html

MacPorts sets the bar for standard support at a reasonable level. If set too high, many ports that build fine with the system clang would needlessly call in a macports-clang for the build.

Some features of c++17 and c++20 are still unimplemented by clang.

and Apple's clang versions are of course related to but not directly translatable to the oss clang versions...

Yes... Of course according to that URL, "Clang 3.4 and later implement all of the ISO C++ 2014 standard". And in MacPorts we declare that Xcode Clang 602 (which is based on a development version of Clang 3.6) and later support C++14. I have not refreshed my memory on how we came to this determination however it seems reasonable to assume that something based on a development version of Clang 3.6 would contain the complete C++14 support that Clang 3.4 contains.

I do recall some instances in the past where Clang initially implemented a new C++ feature in one way, GCC implemented it in a different way, some code could not be compiled with Clang that could be compiled with GCC because Clang interpreted the standard in a stricter manner, and later a clarification of the standard was issued and Clang relaxed its processing to match GCC's. It's possible that this issue with mu is an instance of that situation.