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

[MacPorts]

#63364: mu @1.6.3: error: no matching constructor for initialization of
'value_type' (aka 'pair<const std::__1::basic_string<char>, Container>')
-------------------------+--------------------------------
  Reporter:  ryandesign  |      Owner:  ra1nb0w
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.7.1
Resolution:  fixed       |   Keywords:  yosemite elcapitan
      Port:  mu          |
-------------------------+--------------------------------

Comment (by ryandesign):

 Replying to [comment:7 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/63364#comment:9>
MacPorts <https://www.macports.org/>
Ports system for macOS