Fix lot of stuffs with .*Return*.

[FranckRJ]

Basically what's here: #337.

What this PR do:

• Reintroduce back the support for .Return<type>(obj) and .Return<type&>(obj) to not break to much code with the new update, they are deprecated and shouldn't be used.
• Add ReturnValCapt and ReturnRefCapt to force a capture either by value (move or copy) or by reference, independent of the return type of the mocked function.
• For a function returning T&, ReturnValCapt(U{}) will store the original object if U& can be cast to T& (if T is a parent of U, for example) to avoid object slicing, otherwise a T will be constructed from the U passed by parameter and stored, to avoid creating a temporary (and returning a reference to it) when the mocked function is called.

[coveralls]

coverage: 99.567% (+0.003%) from 99.564%
when pulling cece5b1 on make-return-with-spe-works-again-and-bonuses
into 1eaa63c on dev.

[FranckRJ]

Hello @otrempe and @malcolmdavey, from what I understood from things you said in other issues, you have some codebases that use explicit template specializations for .Return(), like .Return<std::string>(val) to capture the value by copy for a function that returns a reference, or .Return<std::string&>(val) to capture the value by reference for a function that returns a copy.

If you can, I would like you to test this PR with your codebase (I already generated the single headers here: https://github.com/eranpeer/FakeIt/tree/make-return-with-spe-works-again-and-bonuses/single_header), because previous versions of FakeIt 2.5.0-dev disabled this (undocumented) feature, but I tried to add it back, and I would like to know if it works for more complexes use cases than the ones I come up in the unit tests.

I would really like to be able to release 2.5.0 without breaking anyone's code, if anyone can help I would be really grateful.

[malcolmdavey]

Hello @otrempe and @malcolmdavey, from what I understood from things you said in other issues, you have some codebases that use explicit template specializations for .Return(), like .Return<std::string>(val) to capture the value by copy for a function that returns a reference, or .Return<std::string&>(val) to capture the value by reference for a function that returns a copy.

If you can, I would like you to test this PR with your codebase (I already generated the single headers here: https://github.com/eranpeer/FakeIt/tree/make-return-with-spe-works-again-and-bonuses/single_header), because previous versions of FakeIt 2.5.0-dev disabled this (undocumented) feature, but I tried to add it back, and I would like to know if it works for more complexes use cases than the ones I come up in the unit tests.

I would really like to be able to release 2.5.0 without breaking anyone's code, if anyone can help I would be really grateful.

Hi Frank.

As it turns out I hadn't actually used any cases of explicit types yet, but had just added unit tests for fakeit to give more complete coverage.
The main case I was after was being able to construct a value inline, where it will be returned as a reference, and then I need to increase it's lifetime.
This was the only case where I've found a compile error (by design) - though this would also have been affected by the previous merged PR (#332 )

My existing code (using fakeit 2.4 ?)

	When(Method(object, method)).AlwaysReturn({part1, part2});

Now compared to AlwaysReturn/Return, since it doesn't know the type, I need to make the type explicit
by either of these:

	When(Method(object, method)).AlwaysReturnValCapt(MyType{part1, part2});
	When(Method(object, method)).AlwaysReturnValCapt<MyType>({ part1, part2 }});

I guess this is less ideal compared to the behaviour of Return/AlwaysReturn, but it isn't a big deal.
If it's simple to fix that would be great though, assuming there is no down side to it.

[malcolmdavey]

Also found an unrelated compile error here that I posted here
#357

[FranckRJ]

I didn't thought about that, yeah adding a default type for the template so you don't need to explicitly provide one is easy, I tried on Godbolt and it works, I'll change that. Thank you for the suggestion !

Thanks for reporting the bug with msvc, I'll fix that as well.

[FranckRJ]

I think it's in a pretty good state, so I'll merge it now. If issues are found I hope they won't be too big, and they can always be fixed in a later release.