feat: rename ShellOtps to GlobalOpts

[zerosnacks]

Motivation

Related: #8408

Solution

• Renames ShellOpts to GlobalOpts.
• Only selectively passes down GlobalOpts where required, this can be the case when wanting to indicate a conflicts_with a global argument. In most cases when checking against the shell configuration it is probably easier to use the e.g. shell::is_json variant over passing it all the way down.

[grandizzy]

impl looks good! there's a regression re the way rayon thread pool is spawned though, a command like

forge test --show-progress --jobs 3

always fail now with Error: The global thread pool has already been initialized.

same on cast create2

cast create2 --starts-with dead --case-sensitive --deployer 0x0000000000FFe8B47B3e2130213B802212439497 --init-code-hash 0x0c591f26891d6443cf08c5be3584c1e6ae10a4c2f07c5c53218741e9755fb9cd --jobs 5

fails with

Error: The global thread pool has already been initialized.

I think we should keep the current behavior, that is if --jobs flag not passed then we use rayon default (the number of CPUs available) instead single thread.

Probably this one should also follow the config

foundry/crates/cast/src/lib.rs

Lines 2062 to 2063 in a65a5b1

	let num_threads = std::thread::available_parallelism().map_or(1, |n| n.get());
	let found = AtomicBool::new(false);

[zerosnacks]

impl looks good! there's a regression re the way rayon thread pool is spawned though, a command like

Thanks, good catch!

I think we should keep the current behavior, that is if --jobs flag not passed then we use rayon default (the number of CPUs available) instead single thread.

I had implemented it this way to avoid spawning the global thread pool as the vast majority of commands are not multi-threaded, cc @DaniPopes should we spawn by default?

[grandizzy]

wonder how (if) this would also affect the threadpools spawned in deps (and if we want to or not) like compilers

https://github.com/foundry-rs/compilers/blob/034ecd611eef030217c4b363a794226cd50b4b9e/crates/compilers/src/compile/project.rs#L529-L530

[zerosnacks]

wonder how (if) this would also affect the threadpools spawned in deps (and if we want to or not) like compilers

https://github.com/foundry-rs/compilers/blob/034ecd611eef030217c4b363a794226cd50b4b9e/crates/compilers/src/compile/project.rs#L529-L530

Good point, whenever Rayon is first accessed it will spawn a global thread pool with default settings (unless configured).

Right now it will attempt to spawn for a thread for each job here:

foundry/crates/common/src/compile.rs

Line 144 in 9d7557f

foundry_compilers::project::ProjectCompiler::with_sources(project, sources)?

I'm not sure what we are optimizing for - not running with the default settings of available logical CPUs? It seems desirable, unless specifically required to be limited. A possible motivation would be to pay the cost of spawning upfront.

cc @DaniPopes

[zerosnacks]

Decided to remove the global thread pool for now as it requires further discussion and renamed #8408 as a follow-up to add it

outdated

[grandizzy]

lgtm!