Auto add coverage when needed

[lynzrand]

Related Issues

• Related issues: Auto add coverage as dependency when running coverage  #413

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)
  • When compiling iff --enable-coverage is set and the module being built is moonbitlang/core, it automatically includes moonbitlang/core/coverage in the import list for each package. This is because the core library isn't included automatically in core builds, so coverage pacakges will need to be imported manually.
• 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]

From the provided git diff output, I've identified three notable changes and potential issues:

1. Duplicate Coverage Import in Build Commands:

   • In the test cases (crates/moon/tests/test_cases/mod.rs), there are multiple instances where the coverage library is being imported twice (-i ./target/wasm-gc/debug/test/coverage/coverage.mi:coverage). This redundancy could lead to potential conflicts or unnecessary overhead.
   • Suggestion: Remove the duplicate import statements to streamline the build process and avoid potential issues.

2. Uncommented Code in add_coverage_to_core_if_needed Function:

   • The function add_coverage_to_core_if_needed in crates/moonbuild/src/gen/gen_runtest.rs contains a commented-out block of code (// Add coverage library reference to each package). This might indicate that there's a consideration to add coverage library references to each package, but it's currently not implemented.
   • Suggestion: Review the commented-out code and decide whether it should be implemented or removed. If it's necessary, uncomment and ensure it works as intended. If not, remove it to avoid confusion.

3. Potential Hardcoding of Module Names:

   • The constants MOONBITLANG_CORE and MOONBITLANG_COVERAGE are used directly in the add_coverage_to_core_if_needed function. This hardcoding might limit flexibility if the module names need to change in the future.
   • Suggestion: Consider using configuration settings or parameters to allow for dynamic module names. This would make the code more maintainable and adaptable to future changes.

These observations should help in refining the codebase for better performance and maintainability.

[lynzrand]

@lijunchen Do we need tests for this, and how if yes?

[lynzrand]

A couple tests seem to be failing due to the new unused import warning, maybe we need a PR to update those before moving on?

cc @lijunchen

(Oops accidentally hit the close button)

[lijunchen]

maybe we need a PR to update those before moving on?

ok