Add msg, block, and tx global variables to std

[DanielVF]

This adds stdlib support for msg, block, and tx, so that developers can do msg.sender() rather than using assembly.

• import std.{*} works
• import std.{msg, block, tx} works
• msg.calldata() is used instead of msg.data(), to avoid the reserved data keyword.
• block.difficulty() is intentionally absent, since it was deprecated in previous solidity versions.

Also updated the tests to remove the helper functions that were used to work around the lack of these methods.

[axic]

I do wonder if the msg/tx grouping makes any importance here (compared to having msg_caller, tx_origin, etc.). The reason they were under those structs in Solidity is to reduce namespace pollution, as those were builtins. Here everything can be imported granularly, so that problem does not exists here.

It would be different to have effects or context associated with the "special" msg and tx structs, which are not available as primitives/design yet.

TLDR: I'd suggest to not have this wrapping/grouping until context or effects make it more appropriate.

[DanielVF]

I do wonder if the msg/tx grouping makes any importance here (compared to having msg_caller, tx_origin, etc.). The reason they were under those structs in Solidity is to reduce namespace pollution, as those were builtins. Here everything can be imported granularly, so that problem does not exists here.

I think the adoption of Core Solidity is going to live or die by how similar it feels to Solidity. People have tried to make new, better EVM languages, and adoption of all them together has been almost zero. There's danger that if Core Solidity diverges too much, people will just not use it, and stick with what they are familiar with.

So where there's not a compelling reasons to switch up syntax, I'd lean towards keeping things like classic solidity.

[DanielVF]

Will check on the test failure

[mbenke]

The failing test seems to be this one:

Processing: test/examples/dispatch/context.json
Compiling to Hull...
Emitting hull for contract ContextTest
Writing to output1.hull
Generating Yul...
writing output to /home/ben/work/review/build/context.yul
Compiling to bytecode...
Hex output: /home/ben/work/review/build/context.hex
context
Expected 000000000000000000000000000000000000000000000000000000000000000d but got 0000000000000000000000000000000000000000000000000000000000000012
Expected 00000000000000000000000000000000000000000000000000000000000000e1 but got 000000000000000000000000000000000000000000000000000000000000012c

[axic]

Those are the timestamp/blocknumber constants. I think they increase with each transaction.

[DanielVF]

Yeah, will just move this check into the code, against assembly.

[DanielVF]

After further thought, it seems like a better idea for the tests to be deterministic inside a test file json.

I've changed it so that block numbers and timestamps reset to known values at the start of each test json.