Avoid using std::process::exit(0) in ProjectCompiler::compile

[Pronoss]

This pull request replaces a call to std::process::exit(0) in the ProjectCompiler::compile method with a proper Ok(ProjectCompileOutput::new()) return.

PR Checklist

• Added Tests (not required for this minor refactor)
• Added Documentation (inline clarity improved)
• Breaking changes (no)

[mattsse]

ty, yeah we should def remove this.

this is legacy from when this existed directly in foundry and we wanted to exit early.

not sure if this has side-effects in foundry now,

we should check before we merge this @grandizzy

[grandizzy]

@Pronoss thank you, please fix compilation errors

[Pronoss]

@grandizzy
Fixed the compilation error as requested

[Pronoss]

@grandizzy

After some investigation, I've decided to revert the change and keep the original std::process::exit(0) call.

While avoiding exit(0) would be more idiomatic in Rust, replacing it with a return value like Ok(ProjectCompileOutput::default()) isn't currently feasible without introducing a Default bound on C::Language, which breaks compatibility with downstream code (e.g., foundry-cli fails to compile with E0277).

I explored alternative approaches, including returning an Option or a custom Err, but they would require a wider refactor across the entire call chain. Given that, I've opted to keep the current behavior and leave a // TODO: Avoid process::exit(0) comment in the code for future cleanup when a broader change is more appropriate.

Should I add a more detailed comment in the code next to the exit(0) explaining these issues?

[grandizzy]

@grandizzy

After some investigation, I've decided to revert the change and keep the original std::process::exit(0) call.

While avoiding exit(0) would be more idiomatic in Rust, replacing it with a return value like Ok(ProjectCompileOutput::default()) isn't currently feasible without introducing a Default bound on C::Language, which breaks compatibility with downstream code (e.g., foundry-cli fails to compile with E0277).

I explored alternative approaches, including returning an Option or a custom Err, but they would require a wider refactor across the entire call chain. Given that, I've opted to keep the current behavior and leave a // TODO: Avoid process::exit(0) comment in the code for future cleanup when a broader change is more appropriate.

Should I add a more detailed comment in the code next to the exit(0) explaining these issues?

@Pronoss do I get this right that you propose to keep current behavior and only improve TODO comment? If so, can you draft the comment here to check if it makes sense? thanks!

[Pronoss]

@grandizzy Yes, that’s correct — I’ve decided to keep the current std::process::exit(0) call and added a detailed TODO comment in the code explaining why it remains for now.