MOCK_METHOD with an std::pair argument doesn't compile with VS2010 about googlemock

[GoogleCodeExporter]

Joao, judging from the errors, somewhere the code is trying to pass a 
PolicyDomain to where a PolicyNamespace is expected.  I don't see that in the 
code snippet you provided.

Can you try to reduce the actual code to a minimal repro and then post the 
complete, real code and the errors?

Original comment by [email protected] on 31 Jan 2013 at 6:01

[GoogleCodeExporter]

I know it looks like that, that was also my first guess while trying to fix 
this. But this happens even with unused classes; here's a reduced repro:

#include <utility>

class Foo {
 public:
  MOCK_METHOD1(Bar, void(std::pair<int, int>));
};

Just having this in a header is enough to trigger the same compilation error 
(i.e. this class was never instantiated, nor were any expectations set on the 
Bar method). GCC compiles this just fine.

Original comment by [email protected] on 1 Feb 2013 at 10:39

[GoogleCodeExporter]

Joao, I suspect that the bug is in code you didn't show me or in the build 
script.  What you showed in the comment is not the complete code (e.g. it 
doesn't #include gmock.h).  Could you please provide:

1. the *complete real code* (ideally as a file attachment s.t. we know which 
line number is which), and
2. the *complete compiler error messages* for the code in #1.

Ideally, you should also include the compiler command line arguments.  Thanks!

Original comment by [email protected] on 1 Feb 2013 at 5:19

[GoogleCodeExporter]

The code from #2 is really sufficient to trigger the compilation failure. I 
previously built it by adding that code to a chromium unit tests; I've now 
reproduced this again by using the gmock_main project from gmock-1.6.0.zip:

- open the gmock solution
- "gmock" and "gmock_main" projects build just fine
  (I built from Visual Studio; right-click project, Build)
- now add the code from comment #2 to gmock_main.cc
- rebuilding fails

I've attached gmock_main.cc with the modifications and the compiler output.

Original comment by [email protected] on 4 Feb 2013 at 9:43

Attachments:

• gmock_main.cc
• output.txt.txt

[GoogleCodeExporter]

Joao, your version of gMock appears to be a bit out-dated.  The trunk head is 
at r412 now, and looks like this:

https://code.google.com/p/googlemock/source/browse/trunk/src/gmock_main.cc

I've made your change to the trunk head version of gmock_main.cc.  See the 
attachment for what it looks like.  I'm testing it on Windows now...

Original comment by [email protected] on 4 Feb 2013 at 8:02

Attachments:

• gmock_main.cc

[GoogleCodeExporter]

The tests passed for me on Windows, using MSVC 8.0.  The log is at

https://pulse-internal.corp.google.com/dashboard/my/553/logs/stage/Continuous%20
Test%20gMock%20-%20Windows%20CMake%20Release/raw/true/

I'm not sure what is wrong in your case, Joao.  I suggest to try to update your 
gtest/gmock version to the latest.  If that doesn't help, perhaps work with 
some C++ guru familiar with Chrome build (e.g. Nico) to debug it.  Sorry.

Original comment by [email protected] on 4 Feb 2013 at 8:13

[GoogleCodeExporter]

I tried this with an svn checkout; I got revision 412. I opened 
"googlemock-read-only\msvc\2010\gmock.sln" with Visual Studio 2010, and built 
all the projects; it compiled everything without problems.

Then I added this to gmock_main.cc:

#include <utility>

class Foo {
public:
    MOCK_METHOD1(Bar, void(std::pair<int, int>));
};


And recompiling fails with the same error. I've attached both the modified 
gmock_main.cc and the compiler output log. I suspect this is specific to the 
STL pair (and maybe tuple, see the log) shipped with VS2010. Can you try this 
with that version of Visual Studio?

(the complete version is 10.0.40219.1 SP1Rel)

Original comment by [email protected] on 5 Feb 2013 at 10:18

Attachments:

• gmock_main.cc
• output.txt

[GoogleCodeExporter]

The problem lies within this tuple constructor (from C:\Program Files 
(x86)\vs100\VC\include\tuple)

    template<class _Farg0,
        class _Farg1>
        tuple(const pair<_Farg0, _Farg1>& _Right)
        : _Impl(_Right.first, _Right.second, _TAIL_2(_Nil_obj))
        {   // construct copy of _Right
        }

It is more special than the generic tuple constructor with two arguments 
synthesized by the xfwrap include some lines below

// construct from one or more arguments
#define _INCL_FILE_xxtuple0
#include <xfwrap>

Therefore, trying to construct a tuple<pair<T0, T1>> from a pair<T0, T1> 
results in a call to the first constructor mentioned above which in turn tries 
to assign T0 to pair<T0, T1>, yielding the error.

The solution would be to enable the tuple from pair constructor only if T0 and 
T1 from the pair<T0, T1> given as argument match T0 and T1 from the tuple<T0, 
T1> being constructed.

A quick look into the tuple implementation of Visual Studio 2012 revealed the 
bug being fixed as follows:

    template<class _First, \
        class _Second> \
        tuple(pair<_First, _Second>&& _Right, \
            typename enable_if<_Tuple_enable< \
                tuple<_First, _Second>, _Myt>::value, \
                void>::type ** = 0) \
        : _Mybase(tuple<_Second>(_STD forward<_Second>(_Right.second))), \
            _Myfirst(_STD forward<_First>(_Right.first)) \
        {   /* construct by moving pair */ \
        /* no static_assert necessary */ \
        } \

It should not be too hard to port this fix to Visual Studio 2010.

HTH

Original comment by [email protected] on 5 Feb 2013 at 3:02

[GoogleCodeExporter]

To clarify: the problem lies within the single argument tuple constructor 
implementation of Visual Studio 2010. 

I have corrected the tuple-from-pair-constructors, see attached patch file.

Original comment by [email protected] on 28 Feb 2013 at 8:56

Attachments:

• tuple-construction-from-pair.patch

[GoogleCodeExporter]

Another possibility might be to add an unused default parameter to the 
signature of the method to be mocked, so that gmock no longer tries to 
construct the parameter tuple from a single pair.

Original comment by [email protected] on 28 Feb 2013 at 11:28

[GoogleCodeExporter]

Closing this as it's a defect in MSVC and has a workaround.

Original comment by [email protected] on 8 Mar 2013 at 5:29

• Changed state: WontFix