bug(forge): coverage report shows `if/else` branch as uncovered when reading `bytes` from storage

[clauBv23]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge Version: 1.0.0-stable

What version of Foundryup are you on?

foundryup: 1.0.1

What command(s) is the bug in?

forge coverage

Operating System

macOS (Apple Silicon)

Describe the bug

Hey 👋

I noticed that there are a couple of improvements for if/else branch handling in coverage, but I’ve encountered a different edge case that still behaves unexpectedly.

The issue seems to be, when reading bytes from storage and assigning it to a memory variable inside an if/else block, one of the branches is incorrectly marked as uncovered, even though tests execute both branches.
If I replace the storage read with a constant or inline literal, both branches are marked as covered correctly.

For example, this code :

contract Test {
    bytes public optA = bytes("optA");
    bytes public optB = bytes("optB");

    bytes public constant OPT_A = bytes("optA");
    bytes public constant OPT_B = bytes("optB");

    function fun(uint16 _t) public view {
        bytes memory element;

        if (_t == 4) {
            // ✅ works
            // element = bytes("asset opt");
            // element = OPT_A;

            // ❌ doesn't work 
            element = optA;
        } else {
            // ✅ works
            // element = bytes("opt");
            // element = OPT_B;

            // ❌ doesn't work
            element = optB;
        }
    }
}

Let me know if you need a full test contract or repo. Happy to provide one or isolate this further if needed!

[clauBv23]

I tried with uint256, uint256[] and bytes32 and it works properly

[grandizzy]

@clauBv23 thank you, will check. Noticed you test this with v1.0.0 but we're now at v1.2.3, mind to foundryup and make sure it's still reproducible? Thank you!

[clauBv23]

sure, just tried with
forge 1.2.3-stable (a813a2cee7 2025-06-08T15:42:50.507050000Z)
and the same happens

[grandizzy]

thank you, yeah, was able to reproduce, somehow the source maps are off by one line in the failed case so we'll have to rely on first opcode for 2nd branch. It is weird that happens only for bytes memory but all good if you do the same with uint for example.