fix(verify): use configured solc_version (if any) to identify artifact

[grandizzy]

Motivation

reproducible with https://github.com/superform-xyz/SuperVaults/tree/testProdDeployment by running sh ./script/utils/verify_contracts.sh after a forge build (works OK if no cache / forge clean issued before)

• fails with Error: No matching artifact found for SuperVault because artifact was compiled with version within foundry.toml (solc_version = "0.8.23", artifacts added in cache with {Version { major: 0, minor: 8, patch: 23 } key) but we first detect version from solc (which is v0.8.23+commit.f704f362 so parsed as Version { major: 0, minor: 8, patch: 23, build: BuildMetadata("commit.f704f362") } cannot identify cached artifact)
  

  foundry/crates/verify/src/verify.rs

  Lines 278 to 284 in 2c9719e

  	let version = if let Some(ref version) = self.compiler_version {
  	version.trim_start_matches('v').parse()?
  	} else if let Some(ref solc) = config.solc {
  	match solc {
  	SolcReq::Version(version) => version.to_owned(),
  	SolcReq::Local(solc) => Solc::new(solc)?.version,
  	}

Solution

• use configured solc version if any, and then try to figure version out from compiler version

[DaniPopes]

cli arg should come first or alternatively it is merged onto config and then just config is present here

[grandizzy]

good point, just realized https://github.com/superform-xyz/SuperVaults/blob/testProdDeployment/script/utils/verify_contracts.sh#L32C1-L32C49 so not sure we actually need any change here. ...

[strahor-13]

Hey folks, Aleksandar from Tenderly here 👋

We are looking into the issue with Superform team (their verifications are failing on our platform using foundry). They asked us to paste our findings here in case they are helpful:

We are getting compilation errors. Namely, the compiler is unable to find imports for DataTypes.sol and Error.sol.
Looking at the compiler input, I can see that these are defined on path lib/superform-core/src/libraries/* .

Now, looking at DataTypes.sol import inside of the SuperVault.sol file it is being imported from path superform-core/src/types/DataTypes.sol.
Given the remapping of superform-core/=lib/superform-core/, the path where the compiler expects the file is lib/superform-core/src/types/DataTypes.sol. And it cannot find it there, because it is on a similar (but not identical) path: lib/superform-core/src/libraries/DataTypes.sol

Hope some of this info helps.

[strahor-13]

Hey folks, Aleksandar from Tenderly here 👋

We are looking into the issue with Superform team (their verifications are failing on our platform using foundry). They asked us to paste our findings here in case they are helpful:

We are getting compilation errors. Namely, the compiler is unable to find imports for DataTypes.sol and Error.sol. Looking at the compiler input, I can see that these are defined on path lib/superform-core/src/libraries/* .

Now, looking at DataTypes.sol import inside of the SuperVault.sol file it is being imported from path superform-core/src/types/DataTypes.sol. Given the remapping of superform-core/=lib/superform-core/, the path where the compiler expects the file is lib/superform-core/src/types/DataTypes.sol. And it cannot find it there, because it is on a similar (but not identical) path: lib/superform-core/src/libraries/DataTypes.sol

Hope some of this info helps.

Ok, I got confused with similar paths, and imagined an error where there is none. The error actually happens when attempting to import DataTypes.sol in the IBaseForm.sol file. The import path specified is absolute src/types/DataTypes.sol. As there are no remappings for this path in the compilation request, this cannot be resolved. This also happens when trying to import the DataTypes.sol in file IBaseRouter.sol as well as when trying to import Error.solin file DataLib.sol.

From our perspective, this should be fixed by either:

1. Adding relevant remappings
2. Using relative import paths in the solidity code

And I apologise for causing confusion with my initial message 🙏

[grandizzy]

@strahor-13 thank you! I created #9487 to follow up on this issue and will close this PR as it is not really needed. let's continue discussion there