feat(forge): add solc subcommand and utilities

[jpgonzalezra]

Motivation

The "issue 7654" it is proposed to add a new command, forge detect-solc (in this PR "forge solc vr" or "forge solc version-resolving"), which returns the detected version of the Solidity compiler based on the project configuration. This command aims to help users identify compatible versions of the Solidity compiler for different folders in large projects by providing insights into the version resolution algorithm used.

Solution

Added a solc command with the subcommand version-resolving, which retrieves the resolved versions of the Solidity compiler (solc) within the project using the SolcVersionManager from the foundry_compilers library.

• Ex. with solmate project

$ forge solc vr 

[mds1]

Support for the --skip flag that forge build has would be really nice to allow filtering out directories from the results. When I test this, the output is dominated by e.g. lib/ and test/ files that obscure the src/ files of interest (not a blocker for this PR, can be done in a follow up)

[jpgonzalezra]

Thanks for the comments, I can add support for the --skip flag in this PR or another one. And maybe we can add --silent to only print the version, something link:

one version:

• 0.8.15

More than one:

• 0.8.15
• 0.8.25

What do you think guys?

[zerosnacks]

Hi @jpgonzalezra thanks for the PR! Would be great to get this ready to be merged

I support adding the --skip flag to this PR. Perhaps rather than --silent it makes sense to add different levels of verbosity for the logs that are emitted where the lowest level yields:

• 0.8.15
• 0.8.25

And higher levels of verbosity as proposed by you:

- 0.8.15
  - <path>
  - <path>
  - <path>

- 0.8.25
  - <path>
  - <path>
  - <path>

[jpgonzalezra]

@zerosnacks Awesome, I'll fix the conflicts so we can merge. If we want to add anything else, I'll do it in a separate PR. What do you think?

[zerosnacks]

@zerosnacks Awesome, I'll fix the conflicts so we can merge. If we want to add anything else, I'll do it in a separate PR. What do you think?

Great, we can do this as follow ups - not a blocker for me for this PR

[jpgonzalezra]

@zerosnacks I need to make some changes to the PR because there have been significant updates in the compilers repository. See this commit: https://github.com/foundry-rs/compilers/commit/c78e2eacf7db7e571ffacb1f7bb41533decf4581. I believe I need to use the "detect_version" function. I'll work on that. 💪

[zerosnacks]

Thanks @jpgonzalezra! Let me know if you run into any problems

[yash-atreya]

@jpgonzalezra friendly bump here. Do you still have the bandwidth to complete this?

[zerosnacks]

Would it make sense to generalize this to forge compiler --list?

[zerosnacks]

Pending next release of https://github.com/foundry-rs/compilers as it required minor changes upstream to test multi-compiler mode, specifically Vyper.

Command name updated to forge compiler resolve

Updated PR with compiler updates, added JSON compatibility, added verbose / non-verbose mode and added skip flag.

Apart from this blocker, ready for review

[zerosnacks]

cc @grandizzy would you mind doing a final review before merging?

[DaniPopes]

Like the max supported version by compiler?

[zerosnacks]

wonder if it would be useful to add evm version too at some point

like the max supported version by compiler?

Added a follow-up ticket here: https://github.com/foundry-rs/foundry/issues/9125