Scripting borked: No such file or directory (os error 2)

[robriks]

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 (602460e 2023-10-24T00:16:58.926357929Z)

What command(s) is the bug in?

forge script

Operating System

Linux

Describe the bug

Running forge script has started to fail with error "No such file or directory (os error 2)" and I am not sure why.

For example, forge script script/accountGroup/AccountGroup.s.sol on a file that definitely exists (see screenshot) fails.

Relevant items that I have investigated to no avail:

• Deleting ../.svm worked once, but I can no longer use this fix since the .svm file is either no longer being generated or only worked the first time. Have had trouble finding documentation around the .svm file and what generates it. I feel like it is the strongest lead since nuking it fixed the problem once
• Installing z3 prover theorem did not help (problem started on an Ubuntu VM running on Apple M1 silicon, not sure if it is relevant)
• Downloading Solc binary from solc-bin repository and using the local binary did not help
• Cloning the repository to a new environment (cpu architecture, OS) worked for a bit but begins to fail similarly within a day (usually when forge build --force or forge update is invoked). I discovered this by switching to Ubuntu WSL running on Windows 10, which worked briefly before borking. Same for switching to Ubuntu 22.04 desktop on AMD64.
• There is a file I am reading from using vm.readFile() that sometimes doesn't exist, but for months it had given a more verbose warning reminding me to create the file and not caused any issues of this scale. The os error 2 warning is different, and creating the file in both the 0xRails git submodule and the GroupOS parent repository does not resolve the error
• Attempted purging all submodules and re-adding them using forge install purged_submodule did not make a difference
• Tried ensuring remappings from submodules do not overwrite by using declarations in remappings.txt like src/=src/ and test/=test/ etc

Can provide a reference branch to reproduce this issue, but I need to make some changes first.

Please help, I am running out of leads to investigate! I feel like the .svm and the git submodule leads are most relevant since I confirmed issues WRT both, but resolving them does not fix the problem.

Possibly related? forge update fails with errors caused by submodule dependencies like the below:
fatal: Needed a single revision fatal: Unable to find current origin/v1.3.0 revision in submodule path 'lib/forge-std' fatal: Needed a single revision fatal: Unable to find current origin/v4.9.3 revision in submodule path 'lib/openzeppelin-contracts' fatal: Needed a single revision fatal: Unable to find current origin/v0.3.1 revision in submodule path 'lib/erc6551'

[mattsse]

thanks for looking into this.

is this public by any chance?

can you charge the logs that you get from running with RUST_LOG like RUST_LOG=trace forge ...?

[mattsse]

can you also try after foundryup, we fixed a few issues the last few days.

sorry for the inconveniences

[robriks]

Yeah of course! foundryup does not fix the issue. Here are the RUST_LOG=trace outputs, unfortunately there are so many that my terminal cannot fit all of them so it is truncated. If you need more of the logs I can try to find a way to modify my terminal to fit and copy paste the entirety of it.

I think the traces at the end of the logs are probably what we are after anyway. I can also pass the --force flag for more info or provide the solidity-files-cache.json file if that is helpful.

RustTraceLogs.txt

Note that this is the output when run from the Ubuntu on WSL (AMD64 arch) setup.

[mattsse]

hmm, I believe this is a linking bug, but hard to debug/fix without a proper way to reproduce...

could you perhaps try:

• updating all submodules: git submodule update --init --recursive
• forge clean

[robriks]

Unfortunately that did not fix the bug, still getting "No such file or directory (os error 2)"

A linking bug would make sense as the nuking .svm file solution I found was taken from the NixOS thread below, which appears to be a similar issue though I am not using NixOS or a FHS-challenged Linux distro. The fact that I use Ubuntu VMs on both WSL and Apple M1 silicon seems similar enough, but what is confusing is that now the error is appearing on a plain jane Ubuntu AMD64 architecture desktop and vanilla MacOS on M1.
#545

I piped the entire output of the forge script command into the file below in case the truncated output was not enough information.

RustTraceLogs.txt

If these are not enough information to properly debug, I will provide a reproducible branch for you to examine. At the moment one submodule is private so I'd just need to remove that one and delete references to it

[robriks]

@mattsse I've reconfigured the repository for debugging purposes so the problem is directly reproducible. Your help is deeply appreciated as I don't know what else to do. Here is the repository:

https://github.com/0xStation/groupos/tree/linking-bug

The branch I've configured for debugging is called linking-bug so once cloned, be sure to git checkout linking-bug. Then you can see the error for yourself by running:

forge script script/token/NewChain.s.sol --force

I believe the --force flag is required to trigger the bug.

One thing to note is that forge script works when run from a submodule directory:
cd lib/0xrails
forge script script/AccountProxy.s.sol

[mattsse]

unable to compile this because

https://github.com/0xStation/protocol-ops is private

[robriks]

Thanks for the quick support!

I thought I removed it from both the host repository and the 0xRails submodule in the linking-bug branch.

Is it still present for you in the GroupOS linking-bug branch (commit e1b1a28)? Or is it still present for you in the 0xRails submodule (commit 2a77ba9)? Sorry for the issue.

[mattsse]

ptal @Evalir

[robriks]

Sorry to bother, @Evalir, but is there any updates on this?

I have been using forge flatten to collect the files required for running my scripts and then running them in a different directory as a workaround but I would love to be able to use forge script again.

[robriks]

Good news! I seem to have found the offending file, though I have not yet identified the exact problem.

For context, there was a submodule dependency that was using both HardHat and Foundry, so the remappings.txt in the submodule had declared OpenZeppelin using the Hardhat syntax: @openzeppelin/=lib/openzeppelin-contracts/ This was causing some confusion and opacity of compiler errors, only printing "No such file or directory (os error 2)" to the console when running forge script. Once I removed that submodule, the compiler error became much more informative:

What's interesting is that the ERC4337 file causing the problem is one that doesn't contain any contract declaration; only a struct. It's also worth noting that the struct declaration uses the name struct UserOperation { ... } which is also the same name as the file: "UserOperation.sol"

Perhaps Foundry or Solc is expecting to find a contract artifact instead of a lonely struct, or perhaps the lonely struct is not expected to share the same name of the file without a contract. Another thing I can't explain is that simply upgrading the pragma version declaration from ^0.8.13 to ^0.8.19 seems to have cleared up the issue.

I'm relieved to have scripts working again and am hoping this information is enough to help you identify the source of the bug. Let me know if there's any more I can do to help.

[Evalir]

Yep @robriks, glad to hear scripts are working for you again!

I spent some time looking at the issue today, and this is a combination of dependencies having either outdated or extremely complicated remappings, and also a bug on our side in foundry-rs/compilers (foundry-rs/compilers#9). We're working on resolving the compilers bug. It's definitely the first time I see the pragma affecting compilation though.

Wondering if we can close this, to track on compilers?