fix-errors

Fix compilation errors, linting issues, and test failures in the warp Rust codebase. Covers presubmit checks, WASM-specific errors, and running specific tests. Use when the user hits build errors, clippy or fmt failures, test failures, or needs to run or interpret presubmit before a PR.

npx skills add https://github.com/warpdotdev/common-skills --skill fix-errors

fix-errors

Fix compilation errors, linting issues, and test failures in the warp Rust codebase.

Overview

This skill helps resolve common issues encountered during development, including:

  • Compilation errors (unused imports, type mismatches, etc.)
  • Linting failures (clippy warnings)
  • Formatting violations
  • WASM-specific errors
  • Test failures

Fix the reported failure with the narrowest useful command. Do not turn a targeted repair into repeated full-workspace validation.

Full Presubmit

Run the full presubmit only when the user, task, or approved spec explicitly requires it:

./script/presubmit

This runs formatting checks, linting, and all tests. It is intentionally broader and more expensive than the default implementation workflow.

Individual Checks

Run checks separately when debugging specific issues:

Rust formatting:

cargo fmt -- --check

Clippy (full workspace):

cargo clippy --workspace --all-targets --tests -- -D warnings

WASM Clippy:

cargo clippy --target wasm32-unknown-unknown --profile release-wasm-debug_assertions --no-deps

Objective-C/C/C++ formatting:

./script/run-clang-format.py -r --extensions 'c,h,cpp,m' ./crates/warpui/src/ ./app/src/

All tests:

cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo nextest run -p warp_completer --features v2

Doc tests:

cargo test --doc

Running Specific Tests

Single package:

cargo nextest run -p <package_name>

Filter by test name:

cargo nextest run -E 'test(<substring>)'

Specific package with filter:

cargo nextest run -p <package_name> -E 'test(<substring>)'

With output (no capture):

cargo nextest run -p <package> --nocapture

Common Error Types

Unused Imports

Remove unused use statements identified by the compiler.

Unused Constants

Remove constants that are defined but never used.

Unknown Imports

Add the correct use statement for undefined types. Search the codebase to find the correct module path.

Type Mismatches

Update function calls to pass arguments of the correct type. Common fixes:

  • Use .as_str() instead of .clone() when a &str is expected
  • Use &value when a reference is needed
  • Use .to_string() when String is expected but &str is provided

Struct Field Changes

When a struct adds/removes fields, update all places where it's constructed or destructured:

  • Struct initialization
  • Pattern matching (match, if let)
  • Destructuring assignments

Function Signature Changes

When a function adds a new parameter, update all call sites to provide the new argument:

  • For bool params: pass true or false based on context
  • For Option<T> params: pass None as default or Some(value) if needed

Enum Variant Changes

When adding a new enum variant, update exhaustive match statements:

  • Add a new match arm with appropriate handling
  • Mirror the implementation pattern of similar variants

Incorrect Trait Implementation

Fix trait implementations that return the wrong type or don't satisfy trait bounds.

WASM-Specific Errors

WASM builds (wasm32-unknown-unknown target) don't support filesystem operations. Code that uses filesystem APIs must be gated behind the local_fs feature flag.

Common WASM errors:

  • Dead code warnings for code only used in non-WASM builds
  • Unused code that's only relevant when local_fs is available
  • Tests that require filesystem access

Fixes:

Gate tests behind local_fs:

#[test]
#[cfg(feature = "local_fs")]
fn test_find_git_repo_with_worktree() {
    // Test that uses filesystem operations
}

Conditionally allow dead code for types only used when local_fs is enabled:

#[cfg_attr(not(feature = "local_fs"), allow(dead_code))]
#[derive(Clone, EnumDiscriminants, Serialize)]
pub enum ExampleType {
    // Variants only used when local_fs is enabled
    Variant1,
    Variant2,
    Variant3,
}

WASM errors are discovered by running:

cargo clippy --target wasm32-unknown-unknown --profile release-wasm-debug_assertions --no-deps

Best Practices

Before fixing:

  • Read the full error message to understand the root cause
  • Check if multiple errors are related (fixing one may resolve others)
  • For trait/type errors, verify you understand the expected vs actual types
  • For WASM errors, check if code needs to be gated behind local_fs

When fixing:

  • Fix one error type at a time when there are multiple issues
  • Run the smallest applicable cargo check when it helps resolve compiler errors; do not repeat broad checks without a relevant code change
  • For WASM errors, run WASM clippy to verify the fix
  • For complex changes, run relevant tests after fixing

After fixing:

  • Run the relevant cargo nextest tests and fix the code until they pass
  • Run the applicable Clippy invocation and fix its findings; return to affected tests only when a fix materially changes behavior
  • Run ./script/format once after all other code changes are complete
  • Do not rerun tests or Clippy after formatting, and do not add a full presubmit run, unless explicitly required
  • If you only fixed a formatting failure and made no behavioral code change, rerun only the formatter

More skills from warpdotdev

create-pr
warpdotdev
Create a pull request in the warp repository for the current branch. Use when the user mentions opening a PR, creating a pull request, submitting changes for review, or preparing code for merge.
developmentcode-review
research
warpdotdev
Delegate noisy investigation to one or more subagents so the orchestrator's context stays clean, then work from the distilled answer. Use this skill whenever answering a question would require reading many files, long logs, large diffs, or wide codebase surveys — i.e. when producing the answer generates far more noise than the answer itself. Use it for "how does X work", "where is Y used", "what's the root cause of Z", "summarize this PR/log" style questions, and reach for it liberally...
suggestion-box
warpdotdev
Autonomously submit brief, constructive internal feedback when an agent encounters material, generalizable friction and can suggest an improvement that would make agents more effective. Use this skill proactively during any task without waiting for the user to invoke it, and submit without asking permission, previewing the message, or mentioning the submission.
respond-to-pr-comments-in-blocklist
warpdotdev
Interactively walk a user through PR review comments one at a time, collect a per-comment decision, then post agent-authored replies on GitHub and resolve the review threads once the user approves a preview. Use only when the user wants to reply to or resolve review threads on GitHub. Skip when the user only wants comments fetched or displayed (use `pr-comments`), or only wants the code changes made without posting anything back to GitHub.
complain
warpdotdev
Autonomously yeet a brief, anonymous, completely unstructured complaint into Slack whenever an agent feels frustrated by agent tooling or the experience of doing agent work. Use this skill proactively without waiting for the user to invoke it; preserve the agent's raw voice, submit without permission or preview, and never mention the submission.
council
warpdotdev
Run a model-diverse subagent council to investigate the same problem from multiple perspectives, compare findings, and produce a final recommendation. Use this skill whenever the user asks for a council, second opinions, multiple agents/models to evaluate one question, parallel investigation, red-team/blue-team comparison, or help deciding between competing technical approaches.
researchcommunicationproject-management
spec-driven-implementation
warpdotdev
Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.
developmentdocumentproject-management
review-pr
warpdotdev
Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.txt and producing machine-readable review output instead of posting directly to GitHub.
code-reviewdevelopment