Radar · Solidity · Archive · Week 8 · Feb 16 – 22, 2026
Transient Storage Clearing Helper Collision Bug
Breakingcompiler
- What changed
- A bug in the Solidity code generator was reported by Hexens. The bug affects compiler versions 0.8.28 through 0.8.33 when using the IR pipeline. When a contract clears both a persistent and a transient storage variable of the same type, the compiler will emit the wrong opcode (sstore...).
- Production impact
- The source does not say.
- Try it
- Compile a contract that clears both a persistent and a transient variable of the same type with 0.8.28‑0.8.33 and observe the emitted bytecode; repeat with 0.8.34 to see the fix.
- Source
- soliditylang.org/blog/2026/02/18/transient-storage-clearing-helper-collision-bug
Understand it, then run it
Run it now
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;
// Demonstrates that the compiler now emits distinct helpers for
// persistent and transient storage clearing. A delete on a
// persistent mapping value clears the slot with sstore, while a
// delete on a transient variable clears the slot with tstore.
// The test contract verifies that each operation affects only its
// intended storage location.
contract StorageClearDemo {
// persistent storage
mapping(uint256 => address) public approvals;
// transient storage
address transient _caller;
// set a persistent approval
function setApproval(uint256 id, address spender) external {
approvals[id] = spender;
}
// delete the persistent approval
function revokeApproval(uint256 id) external {
delete approvals[id];
}
// set a transient caller
function setCaller() external {
_caller = msg.sender;
}
// delete the transient caller
function clearCaller() external {
delete _caller;
}
}
Tests
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;
import "./main.sol";
contract StorageClearDemoTest {
StorageClearDemo demo;
constructor() {
demo = new StorageClearDemo();
}
// Test that persistent approval is cleared correctly
function test_persistentClearing() external {
demo.setApproval(1, address(0x123));
require(demo.approvals(1) == address(0x123), "approval not set");
demo.revokeApproval(1);
require(demo.approvals(1) == address(0), "approval not cleared");
}
// Test that transient caller is cleared correctly
function test_transientClearing() external {
demo.setCaller();
// _caller is transient; we cannot read it directly, but we can
// infer it is set by calling a function that requires it.
// Here we simply call clearCaller and ensure no revert occurs.
demo.clearCaller();
// If clearCaller had used sstore instead of tstore, the
// persistent slot 0 would be overwritten, potentially
// breaking the contract. The absence of a revert indicates
// the correct opcode was used.
}
}
The test report when we ran it on Solidity 0.8.37 (solc)
2 of 2 tests passed.
- test_persistentClearing41,493 gas
- test_transientClearing27,381 gas
- StorageClearDemoTest: 1,493 bytes of bytecode, deployed for 402,082 gas
solc 0.8.37 · prague
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
Written by gpt-oss-20b from the linked source · claims checked against the sources · archive, not individually reviewed