Inline config is not propagated to derived contracts

[madlabman]

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.4.4-dev

What version of Foundryup are you on?

No response

What command(s) is the bug in?

forge test

Operating System

Linux

Describe the bug

Consider the following test suit:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.24;

import {Test} from "forge-std/Test.sol";

contract Counter {
    uint256 constant TSLOC = 0x042;

    function load() external {
        assembly ("memory-safe") { tstore(TSLOC, 1) }
    }

    function shoot() external {
        bool loaded;
        assembly ("memory-safe") { loaded := tload(TSLOC) }
        require(loaded, "LOAD ME FIRST");
    }
}

contract CounterTestBase is Test {
    Counter public counter;

    function setUp() public {
        counter = new Counter();
    }

    /// forge-config: default.isolate = true
    function test_load_and_shoot_fails() public virtual {
        counter.load();
        vm.expectRevert("LOAD ME FIRST");
        counter.shoot();
    }

    /// forge-config: default.isolate = false
    function test_load_and_shoot_pass() public virtual {
        counter.load();
        counter.shoot();
    }
}

contract CounterTest is CounterTestBase {}

The CounterTestBase contract defines two test functions with inline config, making sure the tests pass regardless of which isolation mode is set via CLI/profile. I think it's reasonable to assume the inline configuration is passed to the derived contract CounterTest and only needs to be overridden there if you're not happy with the base one, which is contrary to the current behaviour.

In the project I'm contributing to, we have multiple abstract base classes as a way to organise test suites and basically avoid code duplication, and chances are other teams use a similar approach. The workaround is clear, but whether to go this way depends on how the Foundry contributors see the inline config working in the described case.

[grandizzy]

@madlabman we'd like to keep this simpler, could you please point to a real use case you need to propagate config, maybe there's a different way we could suggest to approach. thank you

[madlabman]

@grandizzy the example in the issue is pretty close to a real case. There's a function that uses transient storage to store a flag, and another function that allows an action if the flag is set. The same approach is used by two separate contracts with the same interface, so there's a base abstract contract implementing the test for this functionality, and there are two contracts derived from the base one to test the specific contracts. In the "isolated" mode, top‑level calls act like separate transactions, hence clearing the transient storage.

So I think that, without config propagation, there are a few ways to work around the issue:

• have an external function in the base test contract that wraps the calls relying on the transient storage to make them top‑level calls;
• have a helper multicall‑like contract doing pretty much the same as above;
• override the test functions in the derived contracts and apply the inline config there.