Add option to control max build concurrency

[lynzrand]

Related Issues

• Related issues: #____

Type of Pull Request

• Bug fix
• New feature
  • I have already discussed this feature with the maintainers.
• Refactor
• Performance optimization
• Documentation
• Other (please describe):

Does this PR change existing behavior?

• Yes (please describe the changes below)
  • Add -j<N> commandline arg to control parallelism
  • Add an environment variable MOON_MAX_PAR_TASKS to limit the maximum tasks building in parallel
• No

Does this PR introduce new dependencies?

• No
• Yes (please check binary size changes)

Checklist:

• Tests added/updated for bug fixes or new features
• Compatible with Windows/Linux/macOS

[peter-jerry-ye-code-review]

‼️ This code review is generated by a bot. Please verify the content before trusting it.

⚠️ [Incorrect handling of maximum parallelism limit]

• Category: Correctness
• Code Snippet: crates/moonbuild/src/entry.rs in get_parallelism function
• Recommendation: Ensure the environment variable MOON_MAX_PAR_TASKS acts as an upper bound. Modify the logic to:

  let mut parallelism = default_parallelism().unwrap_or(1);
  if let Ok(env_max) = std::env::var("MOON_MAX_PAR_TASKS") {
      let env_max = env_max.parse().context("...")?;
      parallelism = parallelism.min(env_max);
  }
  if let Some(cli_jobs) = opt.parallelism {
      parallelism = parallelism.min(cli_jobs);
  }
  Ok(parallelism)

• Reasoning: The current implementation allows CLI-specified jobs to exceed the environment variable limit, which contradicts the PR description stating the environment variable should "limit the maximum tasks". This could lead to unintended over-parallelization.

⚠️ [Potential test data contamination]

• Category: Correctness
• Code Snippet: test_moon_parallelism() using TestDir::new("test_filter_pkg_with_test_imports.in")
• Recommendation: Change test directory name to match test purpose:

  TestDir::new("test_parallelism.in")

• Reasoning: The test appears to reuse another test's input directory (test_filter_pkg...), which may lead to incorrect test setup and unreliable results. Tests should have isolated, purpose-specific data.

💡 [Undocumented conflict between --no-parallelize and -j]

• Category: Maintainability
• Code Snippet: no_parallelize flag vs parallelism parameter
• Recommendation: Either:
  1. Make --no-parallelize override -j by setting parallelism to 1
  2. Add validation to reject simultaneous use
  3. Update documentation to clarify behavior
• Reasoning: The test uses both -j1 and --no-parallelize, suggesting possible confusion. The current codebase allows these flags to coexist without explicit handling, which could lead to unexpected behavior if values conflict.