Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugger: Allow specification of several breakpoints from cmdline args #1075

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

zaddach
Copy link
Contributor

@zaddach zaddach commented Jan 31, 2025

Currently, only a single -b|--breakpoint argument is accepted from command line. I've changed the argument parsing so that the argument can be specified several times to add several different breakpoints.

Summary by CodeRabbit

  • New Features
    • Enhanced breakpoint functionality to support multiple breakpoints.
    • Expanded command-line interface to allow setting multiple debugging breakpoints simultaneously.
    • Updated help message to indicate that multiple breakpoints can now be specified.

@zaddach zaddach requested a review from a team as a code owner January 31, 2025 05:29
@zaddach zaddach requested review from NoahTheDuke and removed request for a team January 31, 2025 05:29
Copy link
Contributor

coderabbitai bot commented Jan 31, 2025

Walkthrough

The pull request modifies the breakpoint handling in the debugger's command-line interface. The key change is transforming the breakpoint storage from a single optional string to a vector of strings, enabling multiple breakpoints to be set simultaneously. This modification affects the CliArgs struct, its default implementation, and the initialization method, allowing users to specify multiple breakpoints during debugger startup.

Changes

File Change Summary
debugger/src/main.rs - Replaced breakpoint: Option<String> with breakpoints: Vec<String>
- Updated default initialization to create an empty breakpoints vector
- Modified command-line parsing to push breakpoints into a vector
- Altered init method to iterate and set multiple breakpoints
- Updated help message for the -b option

Possibly related PRs

  • Debugger: Fix command parsing on the debugger prompt #1074: The changes in the main PR, which restructure the CliArgs struct to handle multiple breakpoints, are related to the retrieved PR's modifications to the command parsing logic that includes the breakpoint command, as both involve the handling of breakpoints in the debugger.
  • Debugger: Fix deadlock on Windows #1072: The changes in the main PR, which restructure the CliArgs struct to handle multiple breakpoints, are related to the modifications in the retrieved PR that refactor the handling of breakpoints in the DebuggerContext struct, as both involve changes to how breakpoints are managed and processed.

Suggested reviewers

  • tomtau

Poem

🐰 Breakpoints dancing, no longer alone
A vector of pauses, now fully grown
From single to many, our debugger leaps
Catching bugs where complexity sleeps
Code's rhythm changes, with rabbit's delight! 🐞


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
debugger/src/main.rs (2)

329-331: Remove unnecessary space after & operator.

The iteration logic correctly handles multiple breakpoints, but there's a minor style issue.

-            context.breakpoint(& breakpoint);
+            context.breakpoint(&breakpoint);

Line range hint 290-301: Update help text to document multiple breakpoint support.

The help text should mention that multiple breakpoints can be specified using the -b or --breakpoint option multiple times.

                         Options:\n\
                         -g, --grammar <grammar file>    - load .pest grammar\n\
                         -i, --input <input file>        - load input file\n\
                         -r, --rule <rule>               - run rule\n\
-                        -b, --breakpoint <rule>         - breakpoint at rule\n\
+                        -b, --breakpoint <rule>         - breakpoint at rule (can be specified multiple times)\n\
                         -s, --session <session file>    - load session history file\n\
                         -h, --help                      - print this help menu\n\
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8ea0c31 and 78ead19.

📒 Files selected for processing (1)
  • debugger/src/main.rs (4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (7)
  • GitHub Check: Unit, Style, and Lint Testing
  • GitHub Check: check for semver compatibility
  • GitHub Check: check for no_std compatibility
  • GitHub Check: cargo hack check --feature-powerset
  • GitHub Check: Test Coverage
  • GitHub Check: Documentation check
  • GitHub Check: Minimal Versions Testing
🔇 Additional comments (2)
debugger/src/main.rs (2)

225-225: LGTM! Field change enables multiple breakpoints.

The change from Option<String> to Vec<String> appropriately supports storing multiple breakpoints, aligning with the PR objectives.


236-236: LGTM! Breakpoint collection logic is correct.

The implementation correctly:

  • Initializes an empty vector for breakpoints
  • Accumulates multiple breakpoints via push
  • Preserves error handling for missing arguments

Also applies to: 271-275

Copy link
Contributor

@tomtau tomtau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A small formatting fix (it should be fixable by just running cargo fmt)

debugger/src/main.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
debugger/src/main.rs (1)

Line range hint 291-301: Update help text to reflect multiple breakpoint support.

The help text still indicates single breakpoint usage. Consider updating it to clarify that multiple breakpoints can be specified.

-                         -b, --breakpoint <rule>         - breakpoint at rule\n\
+                         -b, --breakpoint <rule>         - add breakpoint at rule (can be specified multiple times)\n\
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 78ead19 and 01bb909.

📒 Files selected for processing (1)
  • debugger/src/main.rs (4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (7)
  • GitHub Check: check for semver compatibility
  • GitHub Check: check for no_std compatibility
  • GitHub Check: cargo hack check --feature-powerset
  • GitHub Check: Unit, Style, and Lint Testing
  • GitHub Check: Minimal Versions Testing
  • GitHub Check: Test Coverage
  • GitHub Check: Documentation check
🔇 Additional comments (4)
debugger/src/main.rs (4)

225-225: LGTM! Field type change enables multiple breakpoints.

The change from Option<String> to Vec<String> appropriately supports storing multiple breakpoints.


236-236: LGTM! Default implementation correctly handles multiple breakpoints.

The implementation properly initializes an empty vector and accumulates breakpoints through the push operation while preserving error handling.

Also applies to: 271-275


329-331: LGTM! Init method properly sets multiple breakpoints.

The implementation correctly iterates over the breakpoints vector to set each breakpoint individually.


Line range hint 225-331: Consider adding tests for multiple breakpoint functionality.

The new multiple breakpoint feature would benefit from test coverage to ensure reliability. Consider adding tests for:

  1. Setting multiple breakpoints via command line
  2. Verifying all breakpoints are active
  3. Edge cases like duplicate breakpoints

Would you like me to help generate test cases for these scenarios?

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
debugger/src/main.rs (1)

329-331: Consider adding error handling for individual breakpoints.

While the implementation correctly processes multiple breakpoints, consider adding error handling to report issues with individual breakpoints without failing the entire initialization.

 for breakpoint in self.breakpoints {
-    context.breakpoint(&breakpoint);
+    if !context.context.rule_exists(&breakpoint) {
+        eprintln!("Warning: Rule '{}' not found in grammar", breakpoint);
+    }
+    context.breakpoint(&breakpoint);
 }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 01bb909 and 85dfb9c.

📒 Files selected for processing (1)
  • debugger/src/main.rs (5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (7)
  • GitHub Check: Unit, Style, and Lint Testing
  • GitHub Check: check for semver compatibility
  • GitHub Check: check for no_std compatibility
  • GitHub Check: Test Coverage
  • GitHub Check: cargo hack check --feature-powerset
  • GitHub Check: Documentation check
  • GitHub Check: Minimal Versions Testing
🔇 Additional comments (3)
debugger/src/main.rs (3)

225-225: LGTM! Field type change enables multiple breakpoints.

The change from Option<String> to Vec<String> appropriately supports storing multiple breakpoints.


236-236: LGTM! Default implementation correctly handles multiple breakpoints.

The implementation properly initializes an empty vector and correctly accumulates breakpoints from command line arguments while preserving error handling.

Also applies to: 271-275


297-297: LGTM! Help message clearly indicates multiple breakpoints support.

The help message update appropriately informs users about the ability to specify multiple breakpoints.

@zaddach
Copy link
Contributor Author

zaddach commented Feb 1, 2025

🧹 Nitpick comments (1)

debugger/src/main.rs (1)> 329-331: Consider adding error handling for individual breakpoints.

While the implementation correctly processes multiple breakpoints, consider adding error handling to report issues with individual breakpoints without failing the entire initialization.

 for breakpoint in self.breakpoints {
-    context.breakpoint(&breakpoint);
+    if !context.context.rule_exists(&breakpoint) {
+        eprintln!("Warning: Rule '{}' not found in grammar", breakpoint);
+    }
+    context.breakpoint(&breakpoint);
 }

That nitpick isn't straightforward to address, as there's easy way to list rules in the DebuggerContext (context.context). The right way would probably be to make DebuggerContext.addBreakpoint return a Result, which would be an error if a grammar is loaded and the rule doesn't exist in the grammar.

Copy link
Contributor

@tomtau tomtau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zaddach it should be all right -- the CI failures seem unrelated to this, that nitpick is ok to ignore for now. You can try rebasing this PR onto the latest

@tomtau tomtau enabled auto-merge (squash) February 2, 2025 01:42
@zaddach
Copy link
Contributor Author

zaddach commented Feb 2, 2025

@zaddach it should be all right -- the CI failures seem unrelated to this, that nitpick is ok to ignore for now. You can try rebasing this PR onto the latest

done.

auto-merge was automatically disabled February 2, 2025 06:18

Head branch was pushed to by a user without write access

@zaddach zaddach force-pushed the multiple_breakpoints_from_cmdline branch from 85dfb9c to 6d4bbcb Compare February 2, 2025 06:18
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
debugger/src/main.rs (1)

329-331: Consider implementing error handling for individual breakpoints.

While the iteration logic is correct, consider implementing error handling for individual breakpoints as suggested in the PR comments. This would allow reporting issues with specific breakpoints without failing the entire initialization process.

Consider this approach:

-        for breakpoint in self.breakpoints {
-            context.breakpoint(&breakpoint);
-        }
+        for breakpoint in self.breakpoints {
+            if let Err(e) = context.context.check_rule_exists(&breakpoint) {
+                eprintln!("Warning: Invalid breakpoint '{}': {}", breakpoint, e);
+            } else {
+                context.breakpoint(&breakpoint);
+            }
+        }

Note: This suggestion assumes the addition of a check_rule_exists method to DebuggerContext as mentioned in the PR comments.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 85dfb9c and 6d4bbcb.

📒 Files selected for processing (1)
  • debugger/src/main.rs (5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (8)
  • GitHub Check: check for semver compatibility
  • GitHub Check: check for no_std compatibility
  • GitHub Check: Unit, Style, and Lint Testing
  • GitHub Check: cargo hack check --feature-powerset
  • GitHub Check: Minimal Versions Testing
  • GitHub Check: Test Coverage
  • GitHub Check: Documentation check
  • GitHub Check: Fuzzing
🔇 Additional comments (3)
debugger/src/main.rs (3)

225-225: LGTM! Field type change enables multiple breakpoints.

The change from Option<String> to Vec<String> correctly implements the ability to store multiple breakpoints.


236-236: LGTM! Default implementation correctly handles multiple breakpoints.

The initialization with an empty vector and the push operation correctly implement the accumulation of multiple breakpoints while preserving error handling.

Also applies to: 271-271


297-297: LGTM! Help message clearly indicates multiple breakpoints support.

The updated help message accurately reflects the new functionality and maintains consistency with other help entries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants