fix(docs): broken links have been repaired (issue #1196) (#1197)

* fix: broken documentation links have been repaired (issue #1196)

* Update src/ethereum_test_vm/opcode.py

---------

Co-authored-by: Mario Vega <[email protected]>

Author: felix314159

docs/consuming_tests/blockchain_test.md

@@ -28,8 +28,8 @@ For each [`Fixture`](#fixture) test object in the JSON fixture file, perform the
 
     1. Determine whether the current block is valid or invalid:
 
-        1. If the [`expectException`](#expectexception-str) field is not present, it is valid, and object must be decoded as a [`FixtureBlock`](#fixtureblock).
-        2. If the [`expectException`](#expectexception-str) field is present, it is invalid, and object must be decoded as a [`InvalidFixtureBlock`](#invalidfixtureblock).
+        1. If the [`expectException`](#-expectexception-transactionexceptionblockexception) field is not present, it is valid, and object must be decoded as a [`FixtureBlock`](#fixtureblock).
+        2. If the [`expectException`](#-expectexception-transactionexceptionblockexception) field is present, it is invalid, and object must be decoded as a [`InvalidFixtureBlock`](#invalidfixtureblock).
 
     2. Attempt to decode field [`rlp`](#-rlp-bytes) as the current block
         1. If the block cannot be decoded:
@@ -192,7 +192,7 @@ Root hash of the parent beacon block.
 
 #### - `rlp`: [`Bytes`](./common_types.md#bytes)
 
-RLP serialized version of the block. Field is only optional when embedded in a [`InvalidFixtureBlock`](#invalidfixtureblock) as the [`rlp_decoded`](#rlp_decoded-optionalfixtureblock) field.
+RLP serialized version of the block. Field is only optional when embedded in a [`InvalidFixtureBlock`](#invalidfixtureblock) as the [`rlp_decoded`](#-rlp_decoded-optionalfixtureblock) field.
 
 #### - `blockHeader`: [`FixtureHeader`](#fixtureheader)
 

docs/consuming_tests/blockchain_test_engine.md

@@ -36,8 +36,8 @@ For each [`HiveFixture`](#hivefixture) test object in the JSON fixture file, per
     2. If [`errorCode`](#-errorcode-optionalnumber) is present:
         - Verify the directive returns an error, and the error code matches the one in [`errorCode`](#-errorcode-optionalnumber), otherwise fail the test.
         - Proceed to the next payload.
-    3. If [`valid`](#-valid-bool) is `false`, verify that the directive returns `status` field of [PayloadStatusV1](https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#payloadstatusv1) as `INVALID`, otherwise fail the test.
-    4. If [`valid`](#-valid-bool) is `true`, verify that the directive returns `status` field of [PayloadStatusV1](https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#payloadstatusv1) as `VALID`, otherwise fail the test.
+    3. If `valid` is `false`, verify that the directive returns `status` field of [PayloadStatusV1](https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#payloadstatusv1) as `INVALID`, otherwise fail the test.
+    4. If `valid` is `true`, verify that the directive returns `status` field of [PayloadStatusV1](https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#payloadstatusv1) as `VALID`, otherwise fail the test.
 
 ## Structures
 

docs/consuming_tests/state_test.md

@@ -20,7 +20,7 @@ However tests generated by the `execution-spec-tests` repository do **not** use
 
 ## Consumption
 
-For each [`Fixture`](#-fixture) test object in the JSON fixture file, perform the following steps:
+For each [`Fixture`](#fixture) test object in the JSON fixture file, perform the following steps:
 
 1. Use [`pre`](#-pre-alloc) as the starting state allocation of the execution environment for the test.
 2. Use [`env`](#-env-fixtureenvironment) to configure the current execution environment.
@@ -32,10 +32,10 @@ For each [`Fixture`](#-fixture) test object in the JSON fixture file, perform th
     4. Attempt to apply the transaction using the current execution environment:
 
         1. If the transaction could not be applied to the current execution context:
-            - If [`expectException`](#-expectexception-str) is empty, fail the test.
-            - If [`expectException`](#-expectexception-str) is not empty, revert the state to the pre-state.
+            - If [`expectException`](#-expectexception-transactionexception) is empty, fail the test.
+            - If [`expectException`](#-expectexception-transactionexception) is not empty, revert the state to the pre-state.
         2. If the transaction could be applied to the current execution context:
-            - If [`expectException`](#-expectexception-str) is not empty, fail the test.
+            - If [`expectException`](#-expectexception-transactionexception) is not empty, fail the test.
 
     5. Compare the resulting post-state root with the expected post-state root contained in the [`hash`](#-hash-hash) field of the current [`FixtureForkPost`](#fixtureforkpost), and fail the test if they do not match.
     6. Compare the resulting logs hash with the expected logs contained in the [`logs`](#-logs-hash) field of the current [`FixtureForkPost`](#fixtureforkpost), and fail the test if they do not match.

docs/filling_tests/debugging_t8n_tools.md

@@ -90,7 +90,7 @@ which writes the response the from the `t8n-server` to the console output:
 }
 ```
 
-The `t8n.sh` is written to the debug directory for all [supported t8n tools](../index.md#transition-tool-support).
+The `t8n.sh` is written to the debug directory for all [supported t8n tools](./transition_tool_support.md).
 
 ## Verifying Test Fixtures via `evm blocktest`
 

docs/filling_tests/filling_tests_vs_code.md

@@ -11,7 +11,7 @@ Implemented test cases can be explored in VS Code's "Testing" View; click on the
 </figure>
 
 !!! note "Testing EVM Features Under Active Development"
-     See [the VS Code section](./filling_tests_dev_fork.md#executing-tests-for-features-under-development) in [Filling Tests for Features under Development](./filling_tests_dev_fork.md) to explore tests targeting EVM features under development.
+     See [the VS Code section](./filling_tests_dev_fork.md#vs-code-setup) in [Filling Tests for Features under Development](./filling_tests_dev_fork.md) to explore tests targeting EVM features under development.
 
 ## Filling and Debugging Test Cases
 

docs/filling_tests/getting_started.md

@@ -53,5 +53,5 @@ This guide describes how to get started with `fill` and commonly-used command-li
 
 1. Learn [useful command-line flags](./filling_tests_command_line.md).
 2. [Execute tests for features under development](./filling_tests_dev_fork.md) via the `--fork` flag.
-3. _Optional:_ [Configure VS Code](../getting_started/setup_vs_code.md) to auto-format Python code and [execute tests within VS Code](./filling_tests_vs_code.md#executing-and-debugging-test-cases).
+3. _Optional:_ [Configure VS Code](../getting_started/setup_vs_code.md) to auto-format Python code and [execute tests within VS Code](./filling_tests_vs_code.md#filling-and-debugging-test-cases).
 4. Implement a new test case, see [Writing Tests](../writing_tests/index.md).

src/ethereum_test_vm/opcode.py

@@ -5097,7 +5097,7 @@ class Opcodes(Opcode, Enum):
     """
     !!! Note: This opcode is under development
 
-    EOFCREATE[initcontainer_index](value, salt, input_offset, input_size)
+    EOFCREATE[initcontainer_index] (value, salt, input_offset, input_size)
     ----
 
     Description