{"owner":"rust-lang","repo":"rust-analyzer","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"## AI Policy\n\nFollow `AI_POLICY.md`. In particular:\n\n- Do not use AI to author issue/PR comments or replies to maintainers.\n- Do not autonomously open issues or pull requests.\n- Do not author code for issues labeled both `E-easy` and `E-has-instructions`.\n- The human contributor must understand the changes and disclose AI use as required by the policy.\n\n\n## Repository Guides\n\n- Architecture and crate ownership: `docs/book/src/contributing/architecture.md`\n- Rust style: `docs/book/src/contributing/style.md`\n- Testing conventions and fixture syntax: `docs/book/src/contributing/testing.md`\n- Contributor workflows: `docs/book/src/contributing/README.md`\n- AI restrictions: `AI_POLICY.md`\n\nRead the relevant sections before making architectural, generated-code, protocol, or test-harness changes.\n\n## Change Workflow\n\n- Find the nearest existing implementation and its tests before adding new code.\n- Extend existing helpers and test harnesses instead of creating parallel abstractions.\n- Keep changes focused and prefer the smallest change that fits the existing design.\n- When fixing a bug, add the smallest fixture that reproduces it and test the behavior through the existing interface.\n\n## Scope and Dependencies\n\n- Treat new `pub` items, public re-exports, and Cargo dependencies as architectural changes, not routine implementation details.\n- Prefer keeping functionality inside the crate that owns the relevant data.\n- Be conservative with crates.io dependencies. Reuse existing dependencies or `stdx`; do not add small helper crates without strong justification.\n\n## Key Invariants\n\n- User-provided Rust code, malformed syntax, broken builds, and proc-macro failures must not cause ordinary IDE features to panic.\n- Assert invariants liberally. For impossible conditions from which the server can recover, prefer `stdx::never!` or `stdx::always!` and return a safe fallback instead of panicking.\n\n## Testing\n\n- Many feature tests use Rust-code fixtures and `expect-test` snapshots. Follow the nearest existing test helper and fixture convention rather than introducing a new test harness.\n- Before planning or writing fixture-based tests, review `docs/book/src/contributing/testing.md` for fixture annotations, `minicore`, and multi-file/multi-crate syntax.\n- Keep Rust fixtures minimal; remove syntax unrelated to the behavior under test.\n- Use unindented multiline raw strings, matching nearby tests.\n- For regressions, first reproduce the failure with a focused test, then implement the fix.\n\n## Generated Code\n\n- Generated files are committed. Edit the generator rather than generated output.\n- Run `cargo xtask codegen` after changing grammar, generated AST definitions, configuration schemas, or other codegen inputs.\n- After adding parser inline tests (`// test name`), run `cargo test -p xtask`, update the relevant expectations, and inspect the generated diff.\n\n## Validation\n\n- Start with the narrowest relevant test: `cargo test -p <crate> <test-name>` or `cargo test -p <crate>`.\n- After Rust changes, run the affected crate's tests and `cargo clippy -p <crate> --all-targets -- --cap-lints warn`; broaden validation when the change crosses crates.\n- Use `cargo lint` to run Clippy on all workspace targets.\n- Run `cargo xtask tidy` for repository-wide structural or generated-code changes.\n- When updating snapshots with `UPDATE_EXPECT=1`, inspect the expectation diff rather than accepting it blindly.\n- Use `RUN_SLOW_TESTS=1 cargo test` when the affected area has slow tests.\n"},"files":{"CLAUDE.md":"## AI Policy\n\nFollow `AI_POLICY.md`. In particular:\n\n- Do not use AI to author issue/PR comments or replies to maintainers.\n- Do not autonomously open issues or pull requests.\n- Do not author code for issues labeled both `E-easy` and `E-has-instructions`.\n- The human contributor must understand the changes and disclose AI use as required by the policy.\n\n\n## Repository Guides\n\n- Architecture and crate ownership: `docs/book/src/contributing/architecture.md`\n- Rust style: `docs/book/src/contributing/style.md`\n- Testing conventions and fixture syntax: `docs/book/src/contributing/testing.md`\n- Contributor workflows: `docs/book/src/contributing/README.md`\n- AI restrictions: `AI_POLICY.md`\n\nRead the relevant sections before making architectural, generated-code, protocol, or test-harness changes.\n\n## Change Workflow\n\n- Find the nearest existing implementation and its tests before adding new code.\n- Extend existing helpers and test harnesses instead of creating parallel abstractions.\n- Keep changes focused and prefer the smallest change that fits the existing design.\n- When fixing a bug, add the smallest fixture that reproduces it and test the behavior through the existing interface.\n\n## Scope and Dependencies\n\n- Treat new `pub` items, public re-exports, and Cargo dependencies as architectural changes, not routine implementation details.\n- Prefer keeping functionality inside the crate that owns the relevant data.\n- Be conservative with crates.io dependencies. Reuse existing dependencies or `stdx`; do not add small helper crates without strong justification.\n\n## Key Invariants\n\n- User-provided Rust code, malformed syntax, broken builds, and proc-macro failures must not cause ordinary IDE features to panic.\n- Assert invariants liberally. For impossible conditions from which the server can recover, prefer `stdx::never!` or `stdx::always!` and return a safe fallback instead of panicking.\n\n## Testing\n\n- Many feature tests use Rust-code fixtures and `expect-test` snapshots. Follow the nearest existing test helper and fixture convention rather than introducing a new test harness.\n- Before planning or writing fixture-based tests, review `docs/book/src/contributing/testing.md` for fixture annotations, `minicore`, and multi-file/multi-crate syntax.\n- Keep Rust fixtures minimal; remove syntax unrelated to the behavior under test.\n- Use unindented multiline raw strings, matching nearby tests.\n- For regressions, first reproduce the failure with a focused test, then implement the fix.\n\n## Generated Code\n\n- Generated files are committed. Edit the generator rather than generated output.\n- Run `cargo xtask codegen` after changing grammar, generated AST definitions, configuration schemas, or other codegen inputs.\n- After adding parser inline tests (`// test name`), run `cargo test -p xtask`, update the relevant expectations, and inspect the generated diff.\n\n## Validation\n\n- Start with the narrowest relevant test: `cargo test -p <crate> <test-name>` or `cargo test -p <crate>`.\n- After Rust changes, run the affected crate's tests and `cargo clippy -p <crate> --all-targets -- --cap-lints warn`; broaden validation when the change crosses crates.\n- Use `cargo lint` to run Clippy on all workspace targets.\n- Run `cargo xtask tidy` for repository-wide structural or generated-code changes.\n- When updating snapshots with `UPDATE_EXPECT=1`, inspect the expectation diff rather than accepting it blindly.\n- Use `RUN_SLOW_TESTS=1 cargo test` when the affected area has slow tests.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"## AI Policy\n\nFollow `AI_POLICY.md`. In particular:\n\n- Do not use AI to author issue/PR comments or replies to maintainers.\n- Do not autonomously open issues or pull requests.\n- Do not author code for issues labeled both `E-easy` and `E-has-instructions`.\n- The human contributor must understand the changes and disclose AI use as required by the policy.\n\n\n## Repository Guides\n\n- Architecture and crate ownership: `docs/book/src/contributing/architecture.md`\n- Rust style: `docs/book/src/contributing/style.md`\n- Testing conventions and fixture syntax: `docs/book/src/contributing/testing.md`\n- Contributor workflows: `docs/book/src/contributing/README.md`\n- AI restrictions: `AI_POLICY.md`\n\nRead the relevant sections before making architectural, generated-code, protocol, or test-harness changes.\n\n## Change Workflow\n\n- Find the nearest existing implementation and its tests before adding new code.\n- Extend existing helpers and test harnesses instead of creating parallel abstractions.\n- Keep changes focused and prefer the smallest change that fits the existing design.\n- When fixing a bug, add the smallest fixture that reproduces it and test the behavior through the existing interface.\n\n## Scope and Dependencies\n\n- Treat new `pub` items, public re-exports, and Cargo dependencies as architectural changes, not routine implementation details.\n- Prefer keeping functionality inside the crate that owns the relevant data.\n- Be conservative with crates.io dependencies. Reuse existing dependencies or `stdx`; do not add small helper crates without strong justification.\n\n## Key Invariants\n\n- User-provided Rust code, malformed syntax, broken builds, and proc-macro failures must not cause ordinary IDE features to panic.\n- Assert invariants liberally. For impossible conditions from which the server can recover, prefer `stdx::never!` or `stdx::always!` and return a safe fallback instead of panicking.\n\n## Testing\n\n- Many feature tests use Rust-code fixtures and `expect-test` snapshots. Follow the nearest existing test helper and fixture convention rather than introducing a new test harness.\n- Before planning or writing fixture-based tests, review `docs/book/src/contributing/testing.md` for fixture annotations, `minicore`, and multi-file/multi-crate syntax.\n- Keep Rust fixtures minimal; remove syntax unrelated to the behavior under test.\n- Use unindented multiline raw strings, matching nearby tests.\n- For regressions, first reproduce the failure with a focused test, then implement the fix.\n\n## Generated Code\n\n- Generated files are committed. Edit the generator rather than generated output.\n- Run `cargo xtask codegen` after changing grammar, generated AST definitions, configuration schemas, or other codegen inputs.\n- After adding parser inline tests (`// test name`), run `cargo test -p xtask`, update the relevant expectations, and inspect the generated diff.\n\n## Validation\n\n- Start with the narrowest relevant test: `cargo test -p <crate> <test-name>` or `cargo test -p <crate>`.\n- After Rust changes, run the affected crate's tests and `cargo clippy -p <crate> --all-targets -- --cap-lints warn`; broaden validation when the change crosses crates.\n- Use `cargo lint` to run Clippy on all workspace targets.\n- Run `cargo xtask tidy` for repository-wide structural or generated-code changes.\n- When updating snapshots with `UPDATE_EXPECT=1`, inspect the expectation diff rather than accepting it blindly.\n- Use `RUN_SLOW_TESTS=1 cargo test` when the affected area has slow tests.\n","category":"root","tokens":876}]}