trailing_return_mock

[rollbear]

I finally found the time and energy to do this. New macros MAKE_MOCK, MAKE_CONST_MOCK and MAKE_STDTMETHOD_MOCK. They all require trailing return type syntax for the function signature, and they deduce the arity of the function from the signature.

@AndrewPaxie, if you have the time and ability, I would really appreciate an extra pair of eyes on this change. It's a big one, and the surprisingly many ways in which different preprocessors handle macros is a huge source of trouble.

This only supports nullary functions if __VA_OPT__ is available, i.e. in C++20 and later (and for MSVC when using /Zc:preprocessor, on a sufficiently recent compiler).

Inofficially nullary functions may work by defining the macro TROMPELOEIL_HAS_GCC_PP, but I have not tested it.

I plan to write documentation and ChangeLog this weekend.

This would be a nice big 10-year anniversary feature.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.40%. Comparing base (a56cee5) to head (fb4f732).
Report is 16 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #341   +/-   ##
=======================================
  Coverage   99.40%   99.40%           
=======================================
  Files          15       15           
  Lines        1344     1344           
  Branches       22       21    -1     
=======================================
  Hits         1336     1336           
  Misses          8        8           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rollbear]

Updated reference manual and FAQ. I'm not sure about how to best update the cookbook.

[rollbear]

Updated all documentation.

[AndrewPaxie]

Review of mock.cpp remains to be done.

[AndrewPaxie]

Working my way through the new documentation, mock.hpp, and the test code. A couple of questions.

Q: Is a templated trailing return type e.g. std::pair<int, int> accepted?
For example,

struct M
{
  MAKE_MOCK(make, auto (int) -> std::pair<int, int>);
};

Q: Why is the number of arguments different between the different implementations of TROMPELOEIL_COUNT() and TROMPELOEIL_COUNT_()?

If TROMPELOEIL_HAS_VA_OPT then at least 16 arguments, [0, ..., 15].
If not TROMPELOEIL_HAS_VA_OPT then at least 17 arguments, [0, ..., 16].

[rollbear]

Q: Is a templated trailing return type e.g. std::pair<int, int> accepted? For example,

Hmm, no. Good catch. What happens is that it assumes std::pair<int is the return type, and int> is a function specifier. Parenthesizing the return type does not solve the problem (I just checked).

Q: Why is the number of arguments different between the different implementations of TROMPELOEIL_COUNT() and TROMPELOEIL_COUNT_()?

The honest answer is that I didn't originally write it so, and changed it when I found out it didn't work. I got an off-by-one error without it. It's not so strange, though. Without __VA_OPT__, there will always be an empty ,, so one extra is required to get the correct count. When using the GCC extension ,##, you also merge away the extra ,, so it's one less for that one too. This is the reason that a nullary signature only works with either __VA_OPT__ or the GCC extension.