forge coverage skips main contract entirely — not shown in CLI table or LCOV output

[web3pavlou]

Summary

When running forge coverage, everything compiles and tests execute successfully.
However, the main contract under test (src/DSCEngine.sol) does not appear anywhere in:

• the CLI coverage summary table, and
• the generated LCOV report.

All other files (scripts, mocks, helper contracts, etc.) appear normally.
This seems to be a regression or instrumentation omission specific to this contract.

1. Project layout:

src/
  DSCEngine.sol
  DWebThreePavlouStableCoin.sol
script/
  DeployDSC.s.sol
  HelperConfig.s.sol
test/Unit/
  DSCEngineTest.t.sol

2. Run:

forge coverage --report lcov

3. Observe that src/DSCEngine.sol is completely missing from both CLI and LCOV output.

---

Example Output

CLI summary:

╭---------------------------------------+-----------------+-----------------+---------------+----------------╮
| File                                                         | % Lines         | % Statements    | % Branches    | % Funcs        |
+====================================================================+
| script/DeployDSC.s.sol                           | 100.00% (12/12) | 100.00% (14/14) | 100.00% (0/0) | 100.00% (1/1)  |
| script/DeployMockWBTC.s.sol                | 0.00% (0/8)     | 0.00% (0/7)     | 100.00% (0/0) | 0.00% (0/1)    |
| script/HelperConfig.s.sol                        | 75.00% (12/16)  | 83.33% (15/18)  | 33.33% (1/3)  | 66.67% (2/3)   |
| src/DWebThreePavlouStableCoin.sol     | 92.86% (13/14)  | 92.31% (12/13)  | 75.00% (3/4)  | 100.00% (2/2)  |
| test/Mocks/...                                          | ...             | ...             | ...           | ...             |
| Total                                 | 56.35% (71/126) | 58.26% (67/115) | 21.05% (4/19) | 58.33% (14/24) |

But src/DSCEngine.sol is missing completely.

LCOV snippet:

TN:
SF:src/DWebThreePavlouStableCoin.sol
DA:48,6
...
end_of_record

No entry exists for src/DSCEngine.sol at all.

---

✅ What Works

• All tests pass (DSCEngineTest.t.sol runs 42 tests, all passing).
• Compilation is clean.
• forge coverage finishes successfully and writes the LCOV file.

❌ What Fails

• The contract under direct test (DSCEngine.sol) is skipped from coverage instrumentation entirely.
• Neither CLI nor LCOV reports include it.

---

⚙️ foundry.toml

[profile.default]
src = "src"
out = "out"
test = "test"
libs = ["lib"]

remappings = [
    "@chainlink/contracts=lib/chainlink-brownie-contracts/contracts/",
    "@openzeppelin/=lib/openzeppelin-contracts/",
    "@forge-std/=lib/forge-std/src/",
]

---

Environment

forge --version
forge Version: 1.4.2-stable
Commit SHA: 828441d243f552f82c5a89bdc818e52bdd57b26b
Build Timestamp: 2025-10-18T08:18:52.010540957Z (1760775532)
Build Profile: maxperf
Solc version: 0.8.29
OS: wsl

---

Additional Context

• src/DSCEngine.sol is imported and used directly in DSCEngineTest.t.sol.
• Coverage worked previously (older Forge builds did include this contract).
• Behavior is identical whether using --report lcov, --report debug, or specifying --contracts src/DSCEngine.sol.

[wesleysmyth]

This is a known issue with forge coverage instrumentation. Several things to check:

1. Use --ir-minimum flag

The default compilation pipeline can miss certain contracts during instrumentation. The IR pipeline handles coverage instrumentation more reliably:

forge coverage --ir-minimum

This uses Solidity's intermediate representation (IR / Yul) for compilation, which produces more accurate coverage data at the cost of slightly slower compilation.

2. Check if the contract is only called via another contract

forge coverage instruments at the source level. If your "main contract" is only ever called through a proxy, factory, or another contract (never directly in tests), the LCOV report may attribute the coverage to the calling contract instead.

Fix: Add at least one test that calls the contract directly:

function test_directCall() public {
    MainContract main = new MainContract();
    main.someFunction(); // Direct call ensures coverage is tracked
}

3. Filter with --match-contract

If you have many contracts, try isolating the one you care about:

forge coverage --match-contract MainContract --ir-minimum

4. Check the LCOV output directly

Sometimes the contract IS in the LCOV data but your viewer (e.g., VS Code coverage gutter) does not display it. Check the raw LCOV:

forge coverage --ir-minimum --report lcov
grep "SF:" lcov.info | sort

Look for your contract's source file in the SF: lines. If it is missing, the instrumentation skipped it.

5. Large contracts / optimizer edge case

If the contract bytecode exceeds ~24KB (the Spurious Dragon limit) or uses heavy optimization, the coverage instrumentation can fail silently. Try:

forge coverage --ir-minimum --optimize false

Or split the contract into smaller units.

6. Abstract contracts and libraries

Abstract contracts and libraries that are never deployed directly will not appear in coverage unless they are inherited/used by a concrete contract that IS deployed in tests.

Known issues

This has been reported in several Foundry issues. The --ir-minimum flag resolved it for most users. If it persists, try updating to the latest Foundry nightly:

foundryup --nightly

The coverage tooling has been actively improved in recent releases.

[sueun-dev]

One more thing to check: you are on Forge 1.4.2, and the current stable line is newer now.

So I would try this order:

foundryup
forge clean
forge coverage --report lcov
grep '^SF:' lcov.info | sort

Then try --ir-minimum only as a workaround, not as the final answer.

The Foundry docs warn that --ir-minimum can make coverage less accurate because code gets inlined. So if DSCEngine.sol still disappears after an upgrade, I would treat it as a coverage bug, not as proof that your tests are wrong.

[web3pavlou]

Firstly, I want to thank everyone for their input. I’ll go ahead and mark this thread as resolved based on the answers provided.

I did manage to solve the issue back then, although I don’t recall the exact step that fixed it. It may have simply been a temporary VS Code issue.

Thanks again for the help and the valuable insights!