Open kristovatlas opened 1 year ago
Hi @kristovatlas, thanks for the report! I see you are working on Mac, are you using a case-insensitive filesystem by any chance? From a glance, it looks like this could be a bug in the project code -- for the sake of building on case-sensitive filesystems, like most Linux systems, the import should be mentioning console.sol
and not Console.sol
if the file is really named console.sol
.
Indeed, the issue seems to be that Foundry is case insensitive but slither is not. Possibly worth documenting, but at least folks can read this issue now.
Reference: https://github.com/foundry-rs/forge-std/issues/104
@kristovatlas I just did a quick test on a Linux system and it appears that foundry does not do any special handling for case sensitiveness -- it fails to build if you have a file "foo.sol" and import "Foo.sol" instead. I'm thinking it just happens to work on macOS because of the filesystem behavior, which handles operations case-insensitively.
I agree it's worth documenting still!
I just bumped into a similar error .. attaching the logs below. This happened in a private Foundry project that uses PRBMath.
I double-checked the file names and the imports paths, and they look all right to me. As in, there's no mismatch between the actual file names stored in version control and the imports in Solidity - they are all the same case.
It looks like the problem is in particular with the sd1x18/Casting.sol
file in PRBMath. But I can't figure out what's going on besides this.
For context, this is the Slither config file that I used:
{
"filter_paths": "lib",
"solc_remaps": [
"@openzeppelin/contracts=lib/openzeppelin-contracts/contracts/",
"@prb/contracts/=lib/prb-contracts/src/",
"@prb/math/=lib/prb-math/src/",
"@prb/test/=lib/prb-test/src/",
"forge-std/=lib/forge-std/src/",
"solarray=lib/solarray/src",
"src/=src/",
"test/=test/"
]
}
Might the problem be that there is an SD1x18.sol
file AND also a sd1x18
folder in lib/prb-math/src
? If yes, then this looks like a bug in Slither to me. Slither should be able to differentiate between folders and files.
Hi @PaulRBerg! I was able to reproduce the problem you describe using Slither 0.9.1 / crytic-compile 0.2.4 + two contracts on a foundry project. The issue seems to happen because there's "Casting.sol" in two different folders (ud60x18 and sd1x18):
A.sol:
pragma solidity ^0.8.17;
import "prb-math/ud60x18/Casting.sol";
contract A {}
B.sol:
pragma solidity ^0.8.17;
import "prb-math/sd1x18/Casting.sol";
contract B {}
However we recently updated the way that Foundry artifacts are parsed, and I'm unable to reproduce the issue any longer with Slither 0.9.2 & crytic-compile 0.3.0 (the latest releases, from a few days ago)
Could you update your local Slither and crytic-compile installations and let us know if that fixes the issue for you too? Thanks!
PS: there should be no need to specify any remappings in the slither config if you're using foundry to build.
Hey @elopez, thanks a lot for the quick answer (on a Sunday, nonetheless!).
I can confirm that upgrading to Slither 0.9.2 fixed the compilation issue, which in hindsight seems unrelated to the case sensitivity problem reported in this issue. Sorry for that.
However, I bumped into yet another bug related to user-defined value types .. I will try to report it and document it in #1352.
Describe the issue:
Slither is unable to locate a library in my Foundry-based Solidity project.
Code example to reproduce the issue:
Console.sol is referenced in the following source files:
contracts/redacted/contracts/governance/ClaimPool.sol:
contracts/redacted/contracts/governance/ClaimPoolX.sol:
foundry.toml:
Console can be found in: lib/forge-std/src/console.sol:
N.B. There seems to be a case mismatch involved
Console.sol
vsconsole.sol
but it doesn't prevent Foundry from compiling; not sure if relevant.Version:
0.9.0
Relevant log output:
No response