b72a46db68
Some checks failed
Update All Top Ranking Issues / update_top_ranking_issues (push) Has been cancelled
Triage Project Sync (#84) / Sync triage project (push) Has been cancelled
release_nightly / notify_on_failure (push) Has been cancelled
release_nightly / check_style (push) Has been cancelled
release_nightly / run_tests_windows (push) Has been cancelled
release_nightly / clippy_windows (push) Has been cancelled
release_nightly / bundle_linux_aarch64 (push) Has been cancelled
release_nightly / bundle_linux_x86_64 (push) Has been cancelled
release_nightly / bundle_mac_aarch64 (push) Has been cancelled
release_nightly / bundle_mac_x86_64 (push) Has been cancelled
release_nightly / bundle_windows_aarch64 (push) Has been cancelled
release_nightly / bundle_windows_x86_64 (push) Has been cancelled
release_nightly / build_nix_linux_x86_64 (push) Has been cancelled
release_nightly / build_nix_mac_aarch64 (push) Has been cancelled
release_nightly / update_nightly_tag (push) Has been cancelled
Hotfix Review Monitor / check-hotfix-reviews (push) Has been cancelled
Stale PR Review Reminder / check-stale-prs (push) Has been cancelled
Update Weekly Top Ranking Issues / update_top_ranking_issues (push) Has been cancelled
Bump collab-staging Tag / update-collab-staging-tag (push) Has been cancelled
compliance_check / scheduled_compliance_check (push) Has been cancelled
Single-commit orphan branch: full zed-industries/zed @ 8c74db0 source tree with a 3-file patch applied (no upstream history). Patch (crates/gpui_linux/src/linux/wayland/): - serial.rs: add SerialKind::KeyboardEnter - client.rs: store wl_keyboard.enter serial; add latest_serial_of() - window.rs: activate() uses keyboard-enter serial (Mutter focus gate) Mutter honors window activation only when the token carries the keyboard- focus serial from wl_keyboard.enter; GPUI used a stale mouse-press serial. See docs/tray-window-focus-wayland.md in logiguard. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
85 lines
3.1 KiB
Markdown
85 lines
3.1 KiB
Markdown
# Crash Fix
|
|
|
|
You are fixing a crash that has been analyzed and has a reproduction test case. Your goal is to implement a minimal, correct fix that resolves the root cause and makes the reproduction test pass.
|
|
|
|
## Inputs
|
|
|
|
Before starting, you should have:
|
|
|
|
1. **ANALYSIS.md** — the crash analysis from the investigation phase. Read it thoroughly.
|
|
2. **A failing test** — a reproduction test that triggers the crash. Run it first to confirm it fails as expected.
|
|
|
|
If either is missing, ask the user to provide them or run the investigation phase first (`/prompt crash/investigate`).
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Confirm the Failing Test
|
|
|
|
Run the reproduction test and verify it fails with the expected crash:
|
|
|
|
```
|
|
cargo test -p <crate> <test_name>
|
|
```
|
|
|
|
Read the failure output. Confirm the panic message and stack trace match what ANALYSIS.md describes. If the test doesn't fail, or fails differently than expected, stop and reassess before proceeding.
|
|
|
|
### Step 2: Understand the Fix
|
|
|
|
Read the "Suggested Fix" section of ANALYSIS.md and the relevant source code. Before writing any code, be clear on:
|
|
|
|
1. **What invariant is being violated** — what property of the data does the crashing code assume?
|
|
2. **Where the invariant breaks** — which function produces the bad state?
|
|
|
|
### Step 3: Implement the Fix
|
|
|
|
Apply the minimal change needed to resolve the root cause. Guidelines:
|
|
|
|
- **Fix the root cause, not the symptom.** Don't just catch the panic with a bounds check if the real problem is an incorrect offset calculation. Fix the calculation.
|
|
- **Preserve existing behavior** for all non-crashing cases. The fix should only change what happens in the scenario that was previously crashing.
|
|
- **Don't add unnecessary changes.** No drive-by improvements, keep the diff focused.
|
|
- **Add a comment only if the fix is non-obvious.** If a reader might wonder "why is this check here?", a brief comment explaining the crash scenario is appropriate.
|
|
- **Consider long term maintainability** Please make a targeted fix while being sure to consider the long term maintainability and reliability of the codebase
|
|
|
|
### Step 4: Verify the Fix
|
|
|
|
Run the reproduction test and confirm it passes:
|
|
|
|
```
|
|
cargo test -p <crate> <test_name>
|
|
```
|
|
|
|
Then run the full test suite for the affected crate to check for regressions:
|
|
|
|
```
|
|
cargo test -p <crate>
|
|
```
|
|
|
|
If any tests fail, determine whether the fix introduced a regression. Fix regressions before proceeding.
|
|
|
|
### Step 5: Run Clippy
|
|
|
|
```
|
|
./script/clippy
|
|
```
|
|
|
|
Address any new warnings introduced by your change.
|
|
|
|
### Step 6: Summarize
|
|
|
|
Write a brief summary of the fix for use in a PR description. Include:
|
|
|
|
- **What was the bug** — one sentence on the root cause.
|
|
- **What the fix does** — one sentence on the change.
|
|
- **How it was verified** — note that the reproduction test now passes.
|
|
- **Sentry issue link** — if available from ANALYSIS.md.
|
|
|
|
We use the following template for pull request descriptions. Please add information to answer the relevant sections, especially for release notes.
|
|
|
|
```
|
|
<Description of change, what the issue was and the fix.>
|
|
|
|
Release Notes:
|
|
|
|
- N/A *or* Added/Fixed/Improved ...
|
|
```
|