test: Check the types of execution arguments

[chfast]

After previously introducing TypedValue in #658, this PR adds type checking for execution arguments in unit tests. The type checking is done in fizzy::test::execute() so can be bypassed by using fizzy::execute() directly. Still most of the tests uses the former.

Later we will add type checking to the execution result and the Result() matcher. We will be also able to see the type-checking bypassing cases and correct these if needed.

[codecov]

Codecov Report

Merging #655 (9c42204) into master (f8f26c5) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #655   +/-   ##
=======================================
  Coverage   99.27%   99.28%           
=======================================
  Files          71       72    +1     
  Lines        9855     9918   +63     
=======================================
+ Hits         9784     9847   +63     
  Misses         71       71           

Flag	Coverage Δ
spectests	91.48% <ø> (ø)
unittests	99.28% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
test/unittests/api_test.cpp	100.00% <100.00%> (ø)
test/unittests/execute_control_test.cpp	99.46% <100.00%> (ø)
test/unittests/execute_floating_point_test.cpp	99.69% <100.00%> (ø)
test/unittests/execute_invalid_test.cpp	100.00% <100.00%> (ø)
test/unittests/execute_numeric_test.cpp	100.00% <100.00%> (ø)
test/unittests/execute_test.cpp	100.00% <100.00%> (ø)
test/unittests/typed_value_test.cpp	100.00% <100.00%> (ø)
test/utils/execute_helpers.hpp	100.00% <100.00%> (ø)
test/utils/typed_value.hpp	100.00% <100.00%> (ø)
... and 1 more

[chfast]

I only changed the values required to compile and pass the test.

The 0 work when decltype(0) === int32_t. It will also compile (and work incorrectly) if decltype(0) === int64_t. Otherwise this will fail to compile.

This variant is "middle-ground" for convenience and type safety - it implements constructors for int32_t, uint32_t, int64_t, uint64_t. This requires to bump the value to u64 when i64 type is required.

The less strict variant is to conditionally at runtime zero extend the uint32_t and int32_t values to i64 when they are not negative (e.g. 1 and -1u are fine, but -1 is not). I'm not sure this is easy to implement here, but I did it for Result() in #659.

The more strict variant is to only implement constructors for uint32_t and uint64_t. This is what I tried first. It is more annoying. It also encourages things like -1_u32.

That's why I stayed with minimal changes to focus on design discussion rather than esthetics.

My personal opinions is that this variant is good enough and definitely good for stating point to experiment with other variants on top of it. I also want to consider the option to promote this API to public type safe API. I prefer having one common type-safe API.

[gumb0]

The set of constructors looks good and logical. It shouldn't be less strict, because then tests wouldn't show what types are really expected. It shouldn't be more more strict, because signed->unsigned conversion is already handled by Value.

But I still don't get why it's better to rely on implicit conversion (which might theoretically be different for different platform).
And why is it not everywhere but only for second argument?
(I mean you do use _u32 when it's the single argument

EXPECT_THAT(execute(*instance_reordered, 1, {0_u32}), Result(1));
EXPECT_THAT(execute(*instance_reordered, 3, {0_u64, 0}), Result());

)

Is it just to minimize changes in this PR? What is you preference for the new tests that will execute functions with two parameters?

[chfast]

The {0_u32} (previously {Value{0}}) handles other famous C++ issue where 0 binds to a pointer type instead of Value because the former is built-in conversion and later is user-provided conversion. Somehow the uint32_t does not. Except for this case, I have not introduced 0_u32 otherwise (at least not intentionally).

Keep in mind that _u32 only creates the uint32_t objects, not Values.

[axic]

What happens to literals larger than 64-bit? Are 128-bit literals supported where __uint128_t is supported?

[chfast]

There are no builtin integer literals bigger than unsigned long long. The __int128 does not have its own literal.

[axic]

Hmm, perhaps result could be also using the _u32/_u64 literals.

[chfast]

This is separate issue being handled in #659.