Conversion from wildcard to class with template constructor is ambiguous

[TimonNoethlichs]

I have found an issue compiling the following code with the Clang compiler, whereas the GCC compiler has no problems.

Clang says:

source>:24:26: error: conversion from 'trompeloeil::wildcard' to '::trompeloeil::param_list_t<void (Variant), 0>' (aka 'Variant') is ambiguous
  REQUIRE_CALL(obj, func(_));
                         ^

Has someone an idea how I can mitigate this issue?

Thanks in advance!

#include <https://raw.githubusercontent.com/rollbear/trompeloeil/develop/include/trompeloeil.hpp>

using trompeloeil::_;

class Variant
{
public:
    template <typename T>
    Variant(const T& value)
    { }
};

class mock_c
{
public:
  MAKE_MOCK1(func, void(Variant));
};

int main()
{
  mock_c obj;

  REQUIRE_CALL(obj, func(_));

  return 0;
}

https://godbolt.org/z/Wf7nzeMeY

[rollbear]

I see that MSVC also complains for the same reason. This is tricky. I'll see what I can do.

[TimonNoethlichs]

I tried to simplify the problem and I got nothing, but some curiosities:

1. Removing both const qualifier makes GCC also fail:

   • from the Variant constructor parameter
   • from the Wildcard conversion operator

2. clang also fails Variant variant = wildcard;

3. MSVC, however, compiles it.

struct Variant 
{
    template <typename T> 
    Variant(const T&) 
    {}
};

struct Wildcard 
{
    template<typename T>
    operator T() 
    const
    {
        return *this;
    }
};

void func(Variant) { };

int main() 
{
    Wildcard wildcard{};

    Variant variant = wildcard;

    func(wildcard);

    return 0;
}

https://godbolt.org/z/bfh5Mj61h

[rollbear]

I can make your example work, but at the cost of reintroducing other old bugs instead. Hopefully I'll find something, but it may take a while.

[rollbear]

Some progress, but not yet there.

This works, but it gives a conversion warning with gcc, which I am not OK with.

https://godbolt.org/z/zrsdvrhKf

So far no success in getting rid of that warning without breaking things even more.

[TimonNoethlichs]

Thank you very much! I integrated your fix explicitly for clang using "#ifdef clang" and left the original for gcc. I hope you find a better solution that makes you happy :).

[AndrewPaxie]

@rollbear: I have seen the conversion warning from GCC before, as reported here: https://godbolt.org/z/zrsdvrhKf .

I'll check my working notes from a couple of years ago and see if the strategy applied then can be reused (sadly I seem to recall it required a rewrite of client code). I also have a new idea to try in the next day or so, and will report success or failure following the experiment.

[AndrewPaxie]

I was hoping ref-qualification (& and &&) of the conversion operators was going to restrict their application, but it created more issues (interesting issues!) and solved no issues. Perhaps they are exactly the reverse of what's needed. Still investigating.

[rollbear]

I have failed to find a better solution, so going with this and suppressing the -Wconversion warning on gcc. Not entirely happy about this. Leaving the issue open until a release has been tagged.