Vscode-cpptools: Ambiguity between conversion operator to reference and rvalue reference

[ytimenkov]

I was playing with trompeloeil mocking framework.

cpptools' static analysis makes lot of use from static_assert's in it and it looks much easier to write tests that it was before with C++98-only frameworks.

However I've noticed that cpptools report some problems which are not problems for compiler.

Type: LanguageService

• OS and Version: CentOS7 with gcc-6
• VS Code Version: 1.25.0 0f080e5267e829de46638128001aeb7ca2d6d50e x64
• C/C++ Extension Version: 0.17.6
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is.

To Reproduce
Minimal example:

#include <trompeloeil.hpp>

struct Mock
{
  MAKE_MOCK1(mock_func, void(int param));
};

int main()
{
  Mock m;

  REQUIRE_CALL(m, mock_func(trompeloeil::ne(0)));

  return 0;
}

Expected behavior
This code doesn't have any problems in problem window.

Actual behavior
This problem is reported (reformatted for convenience)
more than one conversion function
from

• "trompeloeil::make_matcher_return"

to

• "trompeloeil::param_list_t"

applies:

• -- function template "trompeloeil::duck_typed_matcher<Pred, T...>::operator V &() const [with Pred=trompeloeil::lambdas::not_equal, T=<int>]"
• -- function template "trompeloeil::duck_typed_matcher<Pred, T...>::operator V &&() const [with Pred=trompeloeil::lambdas::not_equal, T=<int>]"

Additional information
This mocking framework is single-header and is available from here: https://github.com/rollbear/trompeloeil

@rollbear Are there any references in the standard why this should/may not work?

[rollbear]

Can you try again with the latest fixes on the master branch? I pushed a set of work-arounds, only an hour or so ago, for two clang c++-17 bugs, and the problems are similar enough, and the fix is for exactly that code.

/Björn

On 12 July 2018 15:17:43 CEST, Yuri Timenkov [e-mail] wrote:

I was playing with trompeloeil mocking framework.

cpptools' static analysis makes lot of use from static_assert's in it
and it looks much easier to write tests that it was before with
C++98-only frameworks.

However I've noticed that cpptools report some problems which are not
problems for compiler.

Type: LanguageService

• OS and Version: CentOS7 with gcc-6
• VS Code Version: 1.25.0 0f080e5267e829de46638128001aeb7ca2d6d50e x64
• C/C++ Extension Version: 0.17.6
• Other extensions you installed (and if the issue persists after
  disabling them):
• A clear and concise description of what the bug is.

To Reproduce
Minimal example:

#include <trompeloeil.hpp>

int main()
{
 struct Mock
 {
   MAKE_MOCK1(mock_func, void(int param));
 };
 Mock m;

 REQUIRE_CALL(m, mock_func(ne(0)));

 return 0;
}

Expected behavior
This code doesn't have any problems in problem window.

Actual behavior
This problem is reported (reformatted for convenience)
more than one conversion function
from

• "trompeloeil::make_matcher_return trompeloeil::lambdas::not_equal,
  trompeloeil::lambdas::not_equal_printer, int>"

to

• "trompeloeil::param_list_t"

applies:

• -- function template "trompeloeil::duck_typed_matcher T...>::operator V &() const [with
  Pred=trompeloeil::lambdas::not_equal, T=]"
• -- function template "trompeloeil::duck_typed_matcher T...>::operator V &&() const [with
  Pred=trompeloeil::lambdas::not_equal, T=]"

Additional information
This mocking framework is single-header and is available from here:
https://github.com/rollbear/trompeloeil

@rollbear Are there any references in the standard why this should/may
not work?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/Microsoft/vscode-cpptools/issues/2260

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[rollbear]

F.Y.I. @AndrewPaxie

[ytimenkov]

I've tried master and it still has same issue.

It appears that issue exists only in decltype() context in trompeloeil (I guess that's why this operator is not defined). After I've ran preprocessor for the above example I get squiggles in
using t = decltype((m).trompeloeil_self_mock_func(trompeloeil::ne(0)));

Then I came up with another example, which is completely stand-alone:

struct VeryConvertable
{
    template <typename V>
    operator V&&() const;

    template <typename V>
    operator V&() const;
};

auto test_func(int p1)
{
    return 0;
}

int main()
{
    int b = test_func(VeryConvertable{});
}

While cpptools still report ambiguity, gcc chooses reference overload:

undefined reference to `VeryConvertable::operator int&<int>() const'

Changing test_func signature to either int& p1 or int&& p1 removes ambiguity in cpptools.

[rollbear]

They're only used in unevaluated context to do SFINAE selection for function matching, hence no need for implementation (in fact, it's not even possible to implement them.)

Your VeryConvertable type may not be a fair example for the problem. trompeloeil::duck_typed_matcher has SFINAE conditions to remove some alternatives. It would be nice if the error message included the type of V.

I do not have a quote from the standard handy. I just know that all C++ compilers I know accept it.

• gcc-4.9, gcc-5, gcc-6, gcc-7, gcc-8
• clang-3.7, clang-3.8, clang-3.9, clang-4, clang-5, clang-6.
• MSVC-2015, MSVC-2017

and they are supported with C++11, C++14, C++17 and C++2a, for all compilers that supports each standard.

gcc-4.8, however, does have a problem similar to that reported.

[sean-mcmanus]

So...is there a bug with our extension? 0.17.7-insiders fixed a bunch of erroneous errors (one of our files went from 7 to 1 bogus error with Linux/clang/libc++): https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.7-insiders .

[ytimenkov]

@sean-mcmanus I've tried 0.17.7-insiders and I still get this ambiguity (please see minimal stand-alone snippet in my comment above).
As this code compiles by most of compilers there is something to be improved in the language server (I saw other bug where LS confuses values with references for C++17).

[ytimenkov]

@rollbear I don't think SFINAE in this case makes any difference:

In the first snippet V is int (sorry, Markdown are angle brackets as assumed they're html tag).

What SFINAE (invoke_result_type) tries to filter out is whether call to
template <typename X, typename Y> lambdas::not_equal::operator()(const X& x, const Y& y) const -> decltype(x != y) is valid.

With both T and V being ints and thus both calls with first argument const int& and const int&& are acceptable and both overloads are visible to the compiler. Actually I don't see how invoke_result_type can make any difference between these 2 cases as it checks calling predicate (which return type is always bool) which accepts a pair of const refs (and non-const and rvalue references both bind to it).

If you think something could/should be done in trompeloeil I could file a separate issue into the corresponding repository.

[rollbear]

You're absolutely right that the SFINAE has nothing to do with it. My suspicion was wrong there. But that the conversion operator is templated does have something to do with it. Look at:

https://godbolt.org/g/4Xrcf8

You can choose a number of different compilers with the same result.

I'm asking C++ language lawyers why this is, but have so far not received any answers.

[sean-mcmanus]

Good news -- I reproed the bug from https://github.com/Microsoft/vscode-cpptools/issues/2260#issuecomment-404762909 and tried with 0.17.8-insiders and it appears to be fixed now: https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.8-insiders
.