dd1f362536
The templates for `BeaconBlock`, `BeaconBlockBody` and `BeaconState` are the only ones using a `macro` mechanism for code generation. This prevents using the dot-syntax style `consensusFork.BeaconFoo` in some situations, and also tends to trigger naming conflicts, requiring the `Type` suffix. Furthermore, the `macro` only works for types that are re-defined in every single `ConsensusFork`. Replacing with the simpler but more verbose approach used for other types for consistency and to avoid the downsides of the `macro`. Furthermore, simplify `test_fixture_sanity_blocks` to use `forks` sugar. |
||
|---|---|---|
| .. | ||
| altair | ||
| bellatrix | ||
| capella | ||
| deneb | ||
| phase0 | ||
| README.md | ||
| all_tests.nim | ||
| consensus_spec_tests_preset.nim | ||
| fixtures_utils.nim | ||
| os_ops.nim | ||
| test_fixture_fork.nim | ||
| test_fixture_fork_choice.nim | ||
| test_fixture_light_client_single_merkle_proof.nim | ||
| test_fixture_light_client_sync.nim | ||
| test_fixture_light_client_update_ranking.nim | ||
| test_fixture_sanity_blocks.nim | ||
| test_fixture_sanity_slots.nim | ||
| test_fixture_ssz_generic_types.nim | ||
| test_fixture_transition.nim | ||
README.md
Tests based on scenarios generated from the consensus spec.