fix: use field assignment for non-exhaustive Spec in benchmarks

[jdx]

Summary

• The coverage CI job fails with E0639: cannot create non-exhaustive struct using struct expression in lib/benches/parse.rs
• Benchmarks are compiled as separate crates, so #[non_exhaustive] on Spec prevents struct literal construction
• Fix: use Spec::default() with field assignment instead of struct literal syntax

Test plan

• cargo build --benches compiles successfully
• Coverage CI job passes

🤖 Generated with Claude Code

---

Note

Low Risk
Low risk: changes are confined to benchmark setup code and only adjust Spec construction to compile with #[non_exhaustive] types.

Overview
Fixes lib/benches/parse.rs to stop using Spec { ..Default::default() } struct literals (which fail for #[non_exhaustive] types when benches compile as a separate crate). Bench specs are now created with Spec::default() followed by explicit field assignment for name, bin, and cmd.

^{Written by Cursor Bugbot for commit c3424dc. This will update automatically on new commits. Configure here.}

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a compilation failure in the coverage CI job by adjusting how Spec structs are instantiated within benchmark code. The change ensures compatibility with the #[non_exhaustive] attribute, allowing benchmarks to compile successfully without altering the struct's definition.

Highlights

• CI Fix for non_exhaustive struct: Resolved a E0639 compilation error in the coverage CI job, specifically within lib/benches/parse.rs, which occurred because the #[non_exhaustive] attribute on the Spec struct prevented direct struct literal construction in benchmark crates.
• Spec struct initialization: Modified the build_small_spec and build_large_spec functions to initialize Spec structs using Spec::default() followed by field-by-field assignment, replacing the previous struct literal syntax.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[greptile-apps]

Greptile Summary

This PR fixes a compilation error in lib/benches/parse.rs caused by Spec being annotated with #[non_exhaustive]. Because benchmarks are compiled as a separate crate, the previous struct-literal syntax (even with ..Default::default()) violated Rust's E0639 rule that prohibits non-exhaustive struct construction outside the defining crate.

• Fix in build_small_spec: Replaced struct literal with Spec::default() + field assignments for name, bin, and cmd.
• Fix in build_large_spec: Same pattern applied identically.
• Both changes are mechanically correct and produce semantically equivalent results — all unset fields still receive their Default values as before.

Confidence Score: 5/5

• This PR is safe to merge — it is a minimal, correct fix for a compile error with no logic changes.
• The change is purely mechanical: it swaps a forbidden struct-literal form for the idiomatic Default + field-assignment pattern required when a type is #[non_exhaustive]. No logic is altered, all field values remain identical, and Spec derives Default so Spec::default() is guaranteed to work. There are no new dependencies, no behavioural changes, and the fix directly addresses the stated E0639 compiler error.
• No files require special attention.

Important Files Changed

Filename	Overview
lib/benches/parse.rs	Replaces struct literal construction (forbidden for #[non_exhaustive] types outside the crate) with Spec::default() + field assignment in both build_small_spec and build_large_spec. The fix is correct and complete.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["build_small_spec() / build_large_spec()"] --> B["Spec::default()"]
    B --> C["spec.name = ..."]
    C --> D["spec.bin = ..."]
    D --> E["spec.cmd = cmd"]
    E --> F["return spec"]

    style B fill:#c8f7c5,stroke:#27ae60
    style A fill:#f9f9f9,stroke:#999

Loading

_{Reviews (1): Last reviewed commit: "fix: use field assignment instead of str..." | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request correctly addresses a compilation error in the benchmarks by changing how a #[non_exhaustive] struct is instantiated. The fix is valid. I have added one suggestion to address code duplication that is present in the changes, which would improve the overall maintainability of the benchmark code.

[gemini-code-assist]

This pattern for creating a Spec instance is also used in the build_large_spec function (lines 87-91). To improve maintainability and reduce code duplication, you could extract this logic into a helper function. For example:

fn build_spec_with_cmd(name: &str, bin: &str, cmd: SpecCommand) -> Spec {
    let mut spec = Spec::default();
    spec.name = name.to_string();
    spec.bin = bin.to_string();
    spec.cmd = cmd;
    spec
}

This helper could then be called from both build_small_spec and build_large_spec.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.40%. Comparing base (84a198c) to head (c3424dc).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #552      +/-   ##
==========================================
- Coverage   77.94%   72.40%   -5.54%     
==========================================
  Files          48       48              
  Lines        6682     6830     +148     
  Branches     6682     6830     +148     
==========================================
- Hits         5208     4945     -263     
- Misses       1114     1242     +128     
- Partials      360      643     +283     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.