Execution context generalization

[chfast]

Before #777 lands I propose to generalize ExecutionContext:

• move it to execution_context.hpp,
• rename Guard to something like LocalContext,
• rename increment_call_depth() to something like create_local_context().

[codecov]

Codecov Report

Merging #779 (6095fb6) into master (a1a1b61) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #779   +/-   ##
=======================================
  Coverage   99.24%   99.24%           
=======================================
  Files          78       79    +1     
  Lines       11962    11962           
=======================================
  Hits        11872    11872           
  Misses         90       90           

Flag	Coverage Δ
rust	99.87% <ø> (ø)
spectests	90.54% <100.00%> (ø)
unittests	99.20% <100.00%> (ø)

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

Impacted Files	Coverage Δ
lib/fizzy/execute.hpp	100.00% <ø> (ø)
lib/fizzy/execute.cpp	99.53% <100.00%> (ø)
lib/fizzy/execution_context.hpp	100.00% <100.00%> (ø)
test/unittests/execute_call_depth_test.cpp	100.00% <100.00%> (ø)

[gumb0]

Nit: the commit message Make ExecutionContext::Guard non-copyable/non-movable I think is wrong, as it's still movable, isnt't it?

[gumb0]

Does moving this action from invoke to execute change the depth that host functions see?

[chfast]

No. We record the value in many tests:

fizzy/test/unittests/execute_call_depth_test.cpp

Line 65 in faddd97

recorded_depth = ctx.depth;

.

[gumb0]

I thought so, but why?
Before: call opcode calls invoke_function, it increments depth, calls execute, it calls host function.
After: call opcode calls invoke_function, calls execute, it calls host function. (increment only if it's not imported)

[chfast]

Before: execute(depth: D), call opcode, invoke_function(): increment depth, execute(depth: D+1).
After: execute(depth: D): increment depth, call opcode, invoke_function(), execute(depth: D+1).

So this changes the value of the depth only inside the execute().

This is needed because later I want to get access the ExecutionContext shared stack space in the same place where depth is incremented.

I was not able to also move the depth check to the same place easily. This may be handled later, e.g. by trapping inside the invoke_function().

[chfast]

Nit: the commit message Make ExecutionContext::Guard non-copyable/non-movable I think is wrong, as it's still movable, isnt't it?

To my understanding, move constructor is not implicitly generated if you declare a copy constructor.

[gumb0]

Nit: the commit message Make ExecutionContext::Guard non-copyable/non-movable I think is wrong, as it's still movable, isnt't it?

To my understanding, move constructor is not implicitly generated if you declare a copy constructor.

I think only if you define a custom one, but I might be wrong.

[chfast]

Nit: the commit message Make ExecutionContext::Guard non-copyable/non-movable I think is wrong, as it's still movable, isnt't it?

To my understanding, move constructor is not implicitly generated if you declare a copy constructor.

I think only if you define a custom one, but I might be wrong.

https://godbolt.org/z/14osqo3rG

[gumb0]

Nit: the commit message Make ExecutionContext::Guard non-copyable/non-movable I think is wrong, as it's still movable, isnt't it?

To my understanding, move constructor is not implicitly generated if you declare a copy constructor.

I think only if you define a custom one, but I might be wrong.

https://godbolt.org/z/14osqo3rG

I would add explicit deletions of move contructor and move assignment then.

[chfast]

I would add explicit deletions of move contructor and move assignment then.

OK.