fix: add #[non_exhaustive] to Theme struct

[jdx]

Summary

• Adds #[non_exhaustive] to the Theme struct so new fields can be added without breaking changes
• Users already using ..Theme::default() or ..Default::default() are unaffected
• Prevents the kind of semver-major bump seen in chore: release v2.0.0 #128 / feat: add Wizard component for multi-step wizard flows #127

Test plan

• cargo check passes
• Pre-commit hooks (fmt, clippy) pass
• Existing doc example in theme.rs already uses ..Theme::default() spread syntax

🤖 Generated with Claude Code

---

Note

Low Risk
Small API annotation/doc change; main impact is that downstream code can no longer construct Theme/match CursorShape exhaustively outside the crate.

Overview
Marks the public Theme struct (and CursorShape enum) as #[non_exhaustive] to allow adding new fields/variants without breaking downstream crates.

Updates the doc example to build a theme via Theme::default() and then mutate fields, instead of using a struct literal with ..Theme::default().

^{Written by Cursor Bugbot for commit 4d1422d. 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 improves the forward compatibility of the Theme struct by applying the #[non_exhaustive] attribute. This ensures that the library can evolve by adding new fields to the Theme struct in the future without forcing consumers to update their code, provided they use the recommended spread syntax for initialization. This is a proactive measure to maintain API stability and reduce friction during upgrades.

Highlights

• API Stability: The Theme struct has been marked with #[non_exhaustive], preventing future additions of fields from becoming breaking changes for consumers who use ..Theme::default() or ..Default::default().
• Semantic Versioning: This change aims to avoid semver-major bumps for minor API extensions, addressing issues similar to those seen in chore: release v2.0.0 #128 / feat: add Wizard component for multi-step wizard flows #127.

Changelog

• src/theme.rs
  • Added #[non_exhaustive] attribute to the Theme struct definition.

Activity

• The author confirmed that cargo check passes.
• The author confirmed that pre-commit hooks (fmt, clippy) pass.
• The author noted that existing documentation examples in theme.rs already utilize the ..Theme::default() spread syntax, indicating compatibility.
• The pull request description indicates it was generated with Claude Code.

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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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. ↩

[gemini-code-assist]

Code Review

This pull request introduces the #[non_exhaustive] attribute to the Theme struct. This change prevents consumers of the library from exhaustively constructing the struct, thereby allowing new fields to be added in the future without causing breaking changes. The implementation is correct and achieves the stated goal. No issues were found in this change.

[greptile-apps]

Greptile Summary

This PR marks the public Theme struct as #[non_exhaustive] to allow new fields to be added in future releases without forcing a semver-major bump. The doc example is appropriately updated to use direct field mutation on Theme::default(), which is the correct pattern.

Key concern: The PR title and description only mention #[non_exhaustive] on Theme, but it was also added to the CursorShape enum. This is a separate breaking change: any downstream code that exhaustively pattern-matches on CursorShape without a catch-all arm will now fail to compile. This enum change should be explicitly documented in the PR description and changelog so users know they need to add wildcard arms to exhaustive match statements on CursorShape.

Confidence Score: 2/5

• This PR introduces an undocumented semver-breaking change to the CursorShape enum that will require downstream updates; the change needs explicit documentation before merging.
• The PR correctly marks Theme as #[non_exhaustive] with updated documentation, but silently adds #[non_exhaustive] to the CursorShape enum without mentioning it in the title or description. This will break any downstream code that exhaustively matches on CursorShape without a wildcard arm. While the implementation is correct, the undocumented nature of this breaking change makes it risky to merge without updating the PR description and changelog to call out the enum change and its impact.
• src/theme.rs — update PR description to explicitly mention the CursorShape enum change and its impact on downstream pattern matching.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Downstream crate] --> B{Constructing Theme?}
    B -- "struct literal / update syntax\nTheme { .., ..Theme::default() }" --> C["❌ Compile error\n(non_exhaustive blocks all struct-literal forms)"]
    B -- "field mutation\nlet mut t = Theme::default()\nt.field = value" --> D["✅ Compiles fine"]

    A --> E{Matching CursorShape?}
    E -- "exhaustive match\nBlock => .. / Underline => .." --> F["❌ Compile error\n(non_exhaustive requires wildcard arm)"]
    E -- "match with wildcard\nBlock => .. / Underline => .. / _ => .." --> G["✅ Compiles fine"]

Loading

_{Last reviewed commit: 4d1422d}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Unmentioned non_exhaustive on CursorShape is breaking change

Medium Severity

#[non_exhaustive] was added to CursorShape enum but is not mentioned in the PR title or description (which only references the Theme struct). This is itself a breaking change — external crate users who exhaustively match on CursorShape::Block and CursorShape::Underline without a wildcard arm will get a compilation error. If intentional, it warrants documentation; if unintentional, it may be a mistake.

 

[greptile-apps]

The PR title and description only mention adding #[non_exhaustive] to Theme, but #[non_exhaustive] was also added to the CursorShape enum (lines 7–8). The implications for an enum are distinct: any downstream code that exhaustively pattern-matches on CursorShape without a catch-all arm will now fail to compile, e.g.:

match theme.cursor_shape {
    CursorShape::Block => { /* ... */ }
    CursorShape::Underline => { /* ... */ }
    // ↑ compile error: non-exhaustive patterns, add `_` arm
}

This is a separate semver-breaking change from the Theme struct change. It should be explicitly called out in the PR description and changelog so downstream users know they need to add a wildcard arm to any exhaustive match on CursorShape.