Contributing

Contributions to RustQC are welcome. This page covers how to build, test, and submit changes.

Building

git clone https://github.com/seqeralabs/RustQC.git
cd RustQC

# Debug build
cargo build

# Release build (optimized, used for benchmarking)
cargo build --release

See the Installation page for system dependency requirements (cmake, zlib, bz2, lzma, curl, ssl, clang).

Running tests

# Run all tests (unit + integration)
cargo test

# Run in release mode (matches CI)
cargo test --release

# Run only unit tests
cargo test --lib

# Run only integration tests
cargo test --test integration_test

# Run a specific test by name
cargo test test_dup_rate_calculation

Integration tests in tests/integration_test.rs run the compiled binary as a subprocess and compare output against R-generated reference files in tests/expected/. Do not modify files in tests/expected/ by hand — they are generated by tests/create_test_data.R.

Code formatting and linting

Both checks are enforced in CI and must pass before merging:

# Auto-format code
cargo fmt

# Check formatting without modifying files
cargo fmt --check

# Run clippy (all warnings are errors)
cargo clippy -- -D warnings

RustQC uses default rustfmt settings (no rustfmt.toml) and default clippy settings with -D warnings.

Project structure

RustQC is a binary crate with a nested module structure. Top-level modules are declared in main.rs with no lib.rs. Each reimplemented tool lives in its own submodule under src/rna/. Inter-module access uses crate:: paths.

Code style

Key conventions:

• Default rustfmt formatting, 4-space indentation, trailing commas on multi-line constructs.
• anyhow::Result<T> for all fallible functions. Propagate with ?, add context with .context(). No custom error types.
• Every source file starts with //! module doc comments. All public items have /// doc comments.
• Types are CamelCase, functions/variables are snake_case, constants are SCREAMING_SNAKE_CASE.
• u64 for counts/positions, f64 for metrics, u8 for flags. IndexMap when insertion order matters, HashMap otherwise.
• Unit tests are co-located in each source file inside #[cfg(test)] mod tests. Test names follow test_<description>.
• unwrap() / expect() are restricted to test code only. In production code, use ? with anyhow context.

CI pipeline

GitHub Actions runs on push to main and all pull requests:

1. Test — cargo test --release on Ubuntu and macOS
2. Format — cargo fmt --check
3. Clippy — cargo clippy -- -D warnings

All three checks must pass. The CI uses dtolnay/rust-toolchain@stable and Swatinem/rust-cache@v2.

Submitting changes

1. Fork the repository and create a feature branch.
2. Make your changes, ensuring cargo test, cargo fmt --check, and cargo clippy -- -D warnings all pass locally.
3. Open a pull request against main with a clear description of the changes.