updated docs

Author: felix314159

docs/CHANGELOG.md

@@ -8,6 +8,10 @@ Test fixtures for use by clients are available for each release on the [Github r
 
 ### 💥 Breaking Change
 
+#### 💥 Important Change for test contributors
+
+We do not allow usage of Yul code in your Python tests anymore. Please from now on make use of our opcode wrapper. The only place where Yul code is still allowed is in `static_tests`.
+
 #### 💥 Important Change for `fill` Users
 
 The output behavior of `fill` has changed ([#1608](https://github.com/ethereum/execution-spec-tests/pull/1608)):
@@ -26,7 +30,7 @@ Users can select any of the artifacts depending on their testing needs for their
 #### 🔀 Refactoring
 
 - 🔀 Move `TransactionType` enum from test file to proper module location in `ethereum_test_types.transaction_types` for better code organization and reusability.
-- 🔀 Remove dependency `solc-select` and in CI instead fetch solc 0.8.24 from the official GitHub release. Code changes required involved porting a few Python tests that made use of Yul to our Opcode language ([#1779](https://github.com/ethereum/execution-spec-tests/pull/1779)).
+- 🔀 Remove dependency `solc-select` and in CI instead fetch solc 0.8.24 from the official GitHub release. Code changes required involved porting a few Python tests that made use of Yul to our Opcode language ([#1779](https://github.com/ethereum/execution-spec-tests/pull/1779)). Solc is only needed for filling `static_tests`, from now on it is assumed that the solc binary (v0.8.24) is available in your PATH if you want to fill those.
 
 #### `fill`
 

docs/dev/porting_legacy_tests.md

@@ -85,16 +85,14 @@ Follow the hyperlinks for lost base coverage (`LBC`) to address coverage gaps. H
 
     It's important to note that coverage helps identify missing test paths. If you believe the coverage loss is due to differences in "setup" code between frameworks and doesn't impact the feature you're testing, explain this in your PR. A team member can help with the review.
 
-    Also note that yul tests and possibly other tests used `CALLDATALOAD` that might no longer needed when designing a test with python. But we must always investigate if an opcode is not covered anymore to see if its okay.
-
-    For example, review the [discussion in this PR.](https://github.com/ethereum/execution-spec-tests/pull/975#issuecomment-2528792289)
+    For example, review the [discussion in this PR] to see an example of why and how coverage loss can occur.(https://github.com/ethereum/execution-spec-tests/pull/975#issuecomment-2528792289)
 
 ## Resolving Coverage Gaps from Yul Compilation
 
 When porting tests from ethereum/tests, you may encounter coverage gaps that are false positives. This commonly occurs because:
 
 - **Original tests** often used Yul to define smart contracts, and solc compilation introduces additional opcodes that aren't specifically under test
-- **EEST ports** typically use the explicit EEST Opcode mini-language, which is more precise in opcode definition
+- **EEST ports** use the explicit EEST Opcode mini-language, which is more precise in opcode definition
 
 If coverage analysis shows missing opcodes that were only present due to Yul compilation artifacts (not the actual feature being tested), this can be resolved during PR review by adding the `coverage_missed_reason` parameter:
 

docs/writing_tests/tutorials/blockchain.md

@@ -9,7 +9,6 @@ Before proceeding with this tutorial, it is assumed that you have prior knowledg
 - Repository set-up, see [installation](../../getting_started/installation.md).and run an execution specification test as outlined in the .
 - Able to run `fill`, see [Getting Started: Filling Tests](../../filling_tests/getting_started.md).
 - Understand how to read a [blockchain test](https://ethereum-tests.readthedocs.io/en/latest/test_filler/blockchain_filler.html).
-- Know the basics of [Yul](https://docs.soliditylang.org/en/latest/yul.html), which is an EVM assembly language.
 - Familiarity with [Python](https://docs.python.org/3/tutorial/).
 - Understand how to write an execution spec [state transition test](./state_transition.md).
 
@@ -26,15 +25,7 @@ A smart contract is defined that is called by each transaction in the test. It s
 ```python
 contract_addr: Account(
     balance=1000000000000000000000,
-    code=Yul(
-        """
-        {
-            let next_slot := sload(0)
-            sstore(next_slot, number())
-            sstore(0, add(next_slot, 1))
-        }
-        """
-    ),
+    code=code,
     storage={
         0x00: 0x01,
     },

docs/writing_tests/tutorials/state_transition.md

@@ -1,6 +1,6 @@
 # State Transition Tests
 
-This tutorial teaches you to create a state transition execution specification test. These tests verify that a starting pre-state will reach a specified post-state after executing a single transaction.
+This tutorial teaches you to create a state transition execution specification test. These tests verify that a starting pre-state will reach a specified post-state after executing a single transaction. Note: This tutorial is partly outdated because it still uses Yul code, today we instead only use our Python opcode language.
 
 ## Pre-requisites
 

docs/writing_tests/tutorials/state_transition_bad_opcode.md

@@ -156,10 +156,6 @@ The code can be in either of the following formats:
 - `str`, representing an hexadecimal format of the opcodes.
 - `Code` compilable object.
 
-Currently supported built-in compilable objects are:
-
-- `Yul` object containing [Yul source code](https://docs.soliditylang.org/en/latest/yul.html).
-
 `Code` objects can be concatenated together by using the `+` operator.
 
 ## Verifying the Accounts' Post States
@@ -201,9 +197,6 @@ It can verify the following properties of an account:
 
 - `code`: Bytecode contained by the account. To verify that an account contains
   no code, this property needs to be set to "0x" or "".
-  
-  It is not recommended to verify Yul compiled code in the output account,
-  because the bytecode can change from version to version.
 
 - `storage`: Storage within the account represented as a `dict` object.
   All storage keys that are expected to be set must be specified, and if a