Skip to content

bug(compiler): solc compiler input contains same file multiple times, making build artifacts unusable #246

Open
@0xalpharush

Description

@0xalpharush

Component

Forge

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

  • Foundry
  • Foundryup

What version of Foundry are you on?

forge 0.2.0 (0c961f7 2024-04-07T00:19:04.896666000Z)

What command(s) is the bug in?

forge build

Operating System

macOS (Apple Silicon)

Describe the bug

Foundry's artifacts contain multiple AST's for the same source file and this causes issues in tools like slither which maintain a mapping of source file -> AST. It makes it such that there are multiple reference ID's for what is an "identical" declaration presumably because the solc import resolution fails and adds the entry itself. I believe this is similar to but distinct from gakonst/ethers-rs#2609

Steps to reproduce:

git clone https://github.com/code-423n4/2023-01-timeswap
yarn
cd v2-token
forge build --build-info --skip '*/test/** */script/**' --force
ls out/build-info 
cat $(find out/build-info/*.json)  | jq '.output.sources | keys' |  grep 'node_modules/@openzeppelin/contracts/token/ERC1155/IERC1155.sol'

The output:

  "../../node_modules/@openzeppelin/contracts/token/ERC1155/IERC1155.sol",
  "/Users/alpharush/2023-01-timeswap/node_modules/@openzeppelin/contracts/token/ERC1155/IERC1155.sol",

I expect there only to be one AST for each source unit (file) in each compilation unit (all sources compiled together) as this is should be unique and be an absolute path on disk. This will also causes issue for LSP-like functionality as there would appear to be twice as many declarations in the same file since multiple ASTs are produced with different reference ID's.

As explained in this comment, this happens when the import lookup fails.

I checked the solc compilerinput which looks ok, there's something weird with the output however because it contains duplicate entries for Divider.sol: src/Divider.sol and /src/Divider.sol, this is usually a sign that solc fails to look up an import of a file in the json compilerinput (which works like a virtual file system) and instead tries to find it on disk and also adds this to the compileroutput.

The repo's commit I ran this against:

$ git log
ef4c84fb8535aad8abd6b67cc45d994337ec4514

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

Todo

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions