Solidity v0.8.38 fixes a low-severity bug in the Yul optimizer, makes compilation with the Yul optimizer faster, and warns about identifiers in Yul and inline assembly that are going to be reserved starting from the Amsterdam EVM version.
Yul optimizer bug fix
- When a Yul variable used to compute memory or storage addresses was reassigned, the Yul optimizer did not always notice that its knowledge about those addresses had gone stale.
- As a result, a load could be replaced with an outdated value, or a needed store could be removed.
- Versions 0.8.19 to 0.8.37 are affected, only with the Yul optimizer enabled.
- With
--via-ir, any code may be affected. With the default evmasm pipeline, only compiler-generated Yul utility functions and some inline assembly blocks may be affected. - The fix changed no bytecode in verified contracts on Sourcify, which suggests the bug is very rare.
- The write-up has the details and explains how to check your contracts: Yul Optimizer Knowledge Base Stale Bookkeeping Bug
Other changes
- The release improves the performance of the
DataFlowAnalyzer, which several Yul optimizer steps are built on. As a result, compilation with the Yul optimizer enabled is faster. - In the IR pipeline, the function dispatcher now uses one fewer instruction to check that the calldata is long enough to hold a function selector.
- The compiler now warns when
swapn,dupnorexchangeis used as an identifier in Yul or inline assembly. EIP-8024 adds opcodes with these names in the Amsterdam network upgrade, and the names become reserved starting from the Amsterdam EVM version. Solidity identifiers are not affected.
Links
- Release post: Solidity 0.8.38 Release Announcement | Solidity Programming Language
- Full changelog and downloads: Release Version 0.8.38 · argotorg/solidity · GitHub