eof: Semantic tests update

[rodiazet]

• Disable some tests which don't make sense for EOF.
• Modify tests to make them EOF compatible and move them to separated folders
• Adjust test expectation to avoid using deployed contract address as it can change between optimized and non-optimized versions for EOF

Depends on: #15768 Merged

[cameel]

I found one case where disabling the test actually hides broken behavior (delete on an external function pointer).

In most other cases I commented on we need an EOF version or a TODO to mark the test to be dealt with later.

There were also many tests where a separate EOF version was not really necessary - we can avoid duplication by adjusting the original to work on both EOF and legacy. I actually did that myself while going over the PR (see #15768) so you only need to rebase on that, remove the unnecessary copies for EOF and re-enable the original tests.

[cameel]

This one should have an EOF version.

[cameel]

Also:

• salted_create/prediction_example.sol: calculation on EOF is different, but should still be covered.
• various/create_calldata.sol: on EOF the calldata accessible via msg.data does contain constructor arguments and this should be tested.

[rodiazet]

Problem with event_emit_from_other_contact is that the address in Deposit event expectation depends on contract bytecode. Which makes testing this in semantic tests impossible.

Regarding prediction_example I don't see any option to jest it as we don't have access to contract bytecode and more over the bytecode differs between opt and non-opt versions.

[cameel]

Problem with event_emit_from_other_contact is that the address in Deposit event expectation depends on contract bytecode.

Ah, true. I guess we can't test that now.

Regarding prediction_example I don't see any option to jest it as we don't have access to contract bytecode and more over the bytecode differs between opt and non-opt versions.

Right, my bad. That will only be possible when address calculation in eofcreate gets changed not to include the bytecode hash.

I mean, we could technically consider allowing access to type(C).creationCode, because we know the bytecode, but we probably shouldn't.

[cameel]

#15768 has been merged. Please rebase.

[cameel]

I removed value_complex.sol and value_insane.sol (see #15768 (comment) for context), so we no longer need their EOF versions.

[rodiazet]

done

[cameel]

Already approving since there are just two minor tweaks needed before we can merge.