Debugger next and empty line repeat

[rushsteve1]

Adds two new features to the Pest debugger

• A next command that single-steps the debugger. Most useful after hitting a breakpoint.
• Empty commands repeat the last command (with a message) similar to GDB. Most useful with next or continue.

Summary by CodeRabbit

• New Features
  • Introduced a new "next" command in the debugger, allowing users to step to the next rule.
  • Enhanced command processing so that when an empty command is entered, the previous command is repeated for a smoother debugging experience.
  • Improved the overall event handling to streamline debugger operations.

[coderabbitai]

Walkthrough

The pull request introduces a new stepping mechanism for the debugger. In the library module, a new step_once field is added to the debugger context along with a next method, which allows the debugger to pause execution at the next rule. In the main module, the Cli struct now supports a lifetime parameter to manage borrowed command strings efficiently, and event handling has been refactored into a new receive method. Additionally, empty command input is handled by repeating the last command, and the help output is updated to include the new next command.

Changes

File	Change Summary
debugger/src/lib.rs	Added step_once: Arc<AtomicBool> to DebuggerContext; modified the handle method to check and reset step_once for triggering DebuggerEvent::Breakpoint; added a new next method to control stepping behavior with proper error handling; updated related test cases.
debugger/src/main.rs	Updated Cli struct to include a lifetime parameter with Cow<'a, str> for last_command; refactored event handling by introducing a new receive method called by run, cont, and next methods; modified execute_command to repeat the last command when input is empty; added next command to help output.

Sequence Diagram(s)

sequenceDiagram
    participant U as User
    participant C as CLI
    participant D as DebuggerContext
    participant T as Debugger Thread

    U->>C: Input "next" command
    C->>D: Call next()
    D->>T: Set step_once flag to true
    T->>T: Check step_once flag
    T-->>C: Emit Breakpoint event
    C->>C: Process event in receive()

Loading

Poem

I'm a rabbit in the code, leaping free,
With new steps to debug, I hop with glee.
A flag is set, a break in line,
Events now dance in a refactored design.
Through each rule, I skip and play,
Hopping onward in a joyful code ballet!

---

📜 Recent review details

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

📥 Commits

Reviewing files that changed from the base of the PR and between 111e779 and e1a1a85.

📒 Files selected for processing (2)

• debugger/src/lib.rs (7 hunks)
• debugger/src/main.rs (6 hunks)

🔇 Additional comments (19)

debugger/src/lib.rs (6)

133-133: New field addition for step-once functionality.

The addition of the step_once field as an Arc<AtomicBool> is a good choice for thread safety, allowing the debugger to control single-stepping behavior across thread boundaries.

---

247-247: Good sharing of step_once with the listener thread.

Properly cloning the Arc pointer to the step_once flag ensures the thread will have access to the shared state.

---

258-265: Well-implemented single-step mechanism.

This block properly implements the single-step functionality by:

1. Checking if the step_once flag is set
2. Resetting it immediately to prevent multiple steps
3. Sending a breakpoint event with the current rule and position
4. Returning false to halt execution

The implementation follows the same pattern as the existing breakpoint mechanism while adding the new stepping behavior.

---

362-376: Clear implementation of the next method.

The next method is well-implemented with proper error handling:

1. Checks if debugging is already done
2. Ensures a rule is currently running
3. Sets the step_once flag and unparks the thread
4. Returns appropriate errors when conditions aren't met

The method follows the same pattern as the existing cont method, maintaining consistency in the API.

---

392-392: Proper initialization of the new step_once field.

The field is correctly initialized to false in the Default implementation.

---

444-450: Good test coverage for the new next feature.

The test case properly exercises the new functionality by:

1. Clearing breakpoints to ensure the test is testing the step_once mechanism
2. Calling next() and verifying the correct event is received
3. Checking that execution broke on the expected rule ("digit")

This validates that single-stepping works correctly.

debugger/src/main.rs (13)

18-18: Added Cow import for efficient string handling.

Using Cow (Clone-on-Write) is a good choice for handling the last command, as it avoids unnecessary string cloning.

---

37-41: Improved Cli struct with lifetime parameter.

Adding a lifetime parameter to Cli allows for more efficient string borrowing via Cow<'a, str> for the last_command field, which is a good optimization for command handling.

---

43-43: Updated impl block with lifetime parameter.

Correctly updated the implementation block to match the struct's lifetime parameter.

---

57-61: Refactored run method to use centralized event handling.

The run method has been improved by extracting the event handling logic to the new receive method, reducing code duplication and improving maintainability.

---

63-66: Refactored cont method to use centralized event handling.

Similar to the run method, this refactoring improves consistency and maintainability.

---

68-71: Added next method to support single-stepping.

This method properly calls the underlying next method in the DebuggerContext and uses the centralized event receiving logic, maintaining consistency with the other commands.

---

73-92: Well-implemented centralized event handling.

The new receive method effectively centralizes the event handling logic that was previously duplicated. It handles all debugger events appropriately:

1. Breakpoints - Displays the rule and position
2. EOF - Notifies the user that input was fully processed
3. Errors - Displays the error message
4. Timeouts - Provides feedback on parsing timeouts

This is a good refactoring that improves code organization.

---

113-113: Updated help message with new next command.

The help text is properly updated to include documentation for the new "next" command, maintaining consistency with the rest of the help output.

---

129-141: Well-implemented empty command handling.

This code elegantly handles empty commands by repeating the last executed command:

1. Checks if the current command is empty
2. Uses the last command when empty, with appropriate user feedback
3. Updates the last command otherwise
4. Uses Cow to avoid unnecessary cloning

The implementation is similar to GDB's behavior as mentioned in the PR description.

---

142-147: Improved command parsing.

The command parsing has been updated to work with the new empty command handling logic, properly extracting the verb from the command for matching.

---

149-149: Added handling for empty commands.

The match arm for empty commands is properly added, with a helpful comment indicating that empty commands are handled above.

---

153-153: Added support for the next command.

This line properly handles the "next" command, allowing for prefix matching (e.g., "n" or "ne" will also work) consistent with other commands.

---

337-337: Updated init method signature with lifetime parameter.

The method signature is correctly updated to include the lifetime parameter from the Cli struct.

✨ Finishing Touches

• 📝 Generate Docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 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.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai plan to trigger planning for file edits and PR creation.
• @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.

[rushsteve1]

In comparison to #1080 this PR is dramatically simpler, focused on minor QoL features.

[tomtau]

What's a difference between next and continue?

[tomtau]

feel free to reopen the PR (but maybe better to open a GH issue first to detail what problem it is trying to solve)