trompeloeil: [fixed on master] `compiling_tests` fails with `clang++-6.0 -std=c++17`

Summary

clang++-6.0 on Ubuntu generates an error when compiling Trompeloeil in std=c++17 or std=c++2a modes.

The latest version of Clang also generates this error.

Environment

Operating system: Ubuntu 18.04 LTS (Bionic Beaver)

Compiler: clang++-6.0 and clang++ pre 7.0.0 a.k.a. clang++-latest.

clang++-6.0 is from package clang-6.0 1:6.0-1ubuntu2.

clang++-latest is locally built each day. This build current as at 26 June 2018.

Flags: -std=c++17 or -std=c++2a.

Command line

clang++-6.0 \
-std=c++17 \
-Weverything \
-Wno-c++98-compat-pedantic \
-Wno-padded \
-Wno-weak-vtables \
-Wno-exit-time-destructors \
-Wno-global-constructors \
-I build/catch \
-I ./include \
-o compiling_tests \
test/compiling_tests.cpp \
test/compiling_tests_11.cpp \
test/compiling_tests_14.cpp

Expected behaviour

Expected compiling_tests to build without error.

Actual behaviour

Compile error

/usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/type_traits:945:14: error: base class has incomplete type
    : public is_constructible<_Tp, const _Tp&>
      ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

// ::: (some backtrace information omitted)

test/compiling_tests.hpp:257:3: note: in instantiation of function template specialization 'trompeloeil::call_matcher<void (int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > &),
      std::tuple<trompeloeil::wildcard, trompeloeil::wildcard> >::call_matcher<const trompeloeil::wildcard &, const trompeloeil::wildcard &>' requested here
  MAKE_MOCK2(func, void(int, std::string&), override);
  ^

// ::: (some more backtrace information omitted)

test/compiling_tests_11.cpp:178:26: note: in instantiation of function template specialization 'mock_c::trompeloeil_l_tag_type_trompeloeil_257::func<const trompeloeil::wildcard &, const trompeloeil::wildcard &>' requested here
    REQUIRE_CALL_V(obj2, func(_, _),
                         ^

Further information

This error was encountered as I was gathering information to enable builds of Trompeloeil for C++17 and C++2a.

These build configurations succeed (this is a subset of all the builds that succeed, with a focus on c++17 and c++2a):

                Language    Standard
Compiler        Standard    Library     Comment
----------      --------    --------    -------
g++-5           c++17       stdc++      OK - no warnings, Pass
g++-5           c++17       c++         OK - no warnings, Pass

g++-6           c++17       stdc++      OK - no warnings, Pass
g++-6           c++17       c++         OK - no warnings, Pass

g++-7           c++17       stdc++      OK - no warnings, Pass
g++-7           c++17       c++         OK - no warnings, Pass

g++-8           c++17       stdc++      OK - no warnings, Pass
g++-8           c++17       c++         OK - no warnings, Pass
g++-8           c++2a       stdc++      OK - no warnings, Pass
g++-8           c++2a       c++         OK - no warnings, Pass

g++-latest      c++17       stdc++      OK - no warnings, Pass
g++-latest      c++17       c++         OK - no warnings, Pass
g++-latest      c++2a       stdc++      OK - no warnings, Pass
g++-latest      c++2a       c++         OK - no warnings, Pass

clang++-5.0     c++17       stdc++ v8   OK - no warnings, Pass
clang++-5.0     c++17       c++         OK - no warnings, Pass
clang++-5.0     c++2a       stdc++ v8   OK - no warnings, Pass
clang++-5.0     c++2a       c++         OK - no warnings, Pass

clang++-6.0     c++11       stdc++ v8   OK - no warnings, Pass
clang++-6.0     c++11       c++         OK - no warnings, Pass
clang++-6.0     c++14       stdc++ v8   OK - no warnings, Pass
clang++-6.0     c++14       c++         OK - no warnings, Pass

clang++-latest  c++11       stdc++ v8   OK - no warnings, Pass
clang++-latest  c++11       c++         OK - no warnings, Pass
clang++-latest  c++14       stdc++ v8   OK - no warnings, Pass
clang++-latest  c++14       c++         OK - no warnings, Pass

Note that clang++-6.0 and clang++-latest succeeded in c++11 and c++14 modes.

Either something is wrong with clang++-6.0 in the c++17 and c++2a modes, or Clang has implemented a change from a proposal that has has had an affect on type deduction.

A quick look at the Clang bugzilla does not immediately reveal a previously filed defect report describing this problem.

It is the return of the user-defined conversion problems with wildcard, but I’m left a little concerned there is a limited chance of a workaround in the library code.

I’m raising this issue here, now, before I reduce the test case to the minimum required to reproduce the issue. I will add a comment with the test case once I have it.

Ideas or pointers on how to resolve this are welcomed.