conformance: solc's ethdebug gives imported code the contract's own source id #329

solc's ethdebug output gives every instruction the source id of the contract's own file, including instructions generated from imported files. The byte ranges are right, but they point into the wrong file, so a debugger shows the right offsets in the wrong source.

Seen with solc 0.8.37 (0.8.37+commit.f401782d), 0.8.30 and the argotorg/solidity #16990 build, with viaIR: true, the optimizer off, experimental: true and debug.debugInfo: ["ethdebug", "ast-id"].

Repro, two files:

// Lib.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
library Lib {
    function twice(uint256 x) internal pure returns (uint256) {
        return x * 2;
    }
}

// Main.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "./Lib.sol";
contract Main {
    uint256 public v;
    function set(uint256 x) external {
        v = Lib.twice(x);
    }
}

solc assigns Lib.sol id 0 and Main.sol id 1. In Main's evm.deployedBytecode.ethdebug, all 416 instructions have context.code.source.id: 1. The classic evm.deployedBytecode.sourceMap for the same build attributes 19 of them to file 0. For example, instruction 398 (offset 590):

• classic source map: 74:87:0, which is function twice(...) { return x * 2; } in Lib.sol
• ethdebug: {"source": {"id": 1}, "range": {"offset": 74, "length": 87}}, which points at bytes 74–160 of Main.sol

On a larger contract (LaunchList, verified on mainnet) about 15% of executed instructions come from imported files and carry the wrong id.

Our conformance checks validate solc's output against the schemas, which this passes; the id is valid, just wrong. A check that compares ethdebug code ranges with the classic source map would catch it.

To close this:

• solc writes the id of the file each instruction's range is in.
• Add a conformance check that the ethdebug code source ids agree with the classic source map's file indices.