rust-ownership_skill

This skill analyzes Rust ownership patterns, diagnoses common errors, and guides safe borrowing, lifetimes, and memory management to prevent compile-time

Shell

20

GitHub Stars

3

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill huiali/rust-skills --skill rust-ownership

SKILL_EN.md1.4 KB
SKILL_ZH.md5.6 KB
SKILL.md7.3 KB

Overview

This skill is an ownership, borrowing, and lifetime expert for Rust. It diagnoses common compiler errors (E0382, E0597, E0506, E0507, E0515, E0716, E0106) and proposes systematic, code-level solutions and design alternatives. It focuses on concrete patterns, smart pointer selection, and checklist-driven verification to restore memory-safety and maintainable code.

How this skill works

The skill inspects code snippets, compiler error messages, and call-site relationships to identify the root ownership pattern (moved value, borrow conflict, lifetime mismatch, temporary lifetime). It recommends minimal fixes (references, clone, bind-to-variable) and design changes (return owned types, use Arc/Rc, interior mutability) while explaining trade-offs. It also maps problems to verification steps and commands to validate fixes.

When to use it

When the compiler reports ownership/borrow/lifetime errors (E0382, E0597, E0506, E0507, E0515, E0716, E0106)
During code reviews to validate ownership clarity and borrow scopes
When deciding between references, owned returns, or smart pointers
While designing concurrent or shared-data subsystems
To avoid clone abuse and unnecessary lifetime complexity

Best practices

Identify the data owner first: function parameters are caller-owned, locals are function-owned
Prefer borrowing for reads and owned returns when lifetimes complicate APIs
Use named lifetimes only where inference fails (structs, impls, method returns)
Choose smart pointers by scenario: Box, Rc, Arc, RefCell, Mutex/RwLock as appropriate
Avoid clone() as a patch; prefer clear ownership or explicit shared ownership

Example use cases

Fix E0382 by deciding owner or cloning only when value semantics are required
Resolve E0597/E0716 by binding temporaries to variables or returning owned types
Refactor borrow conflicts (E0506) by shortening borrow scopes or reordering mutations
Select Arc<T> vs Rc<T> when converting single-threaded sharing to multi-threaded
Replace pervasive lifetime annotations by returning owned collections or using smart pointers

FAQ

Return a reference when the caller already owns the data and you can guarantee the lifetime; return an owned value when tying lifetimes is awkward or the caller needs ownership.

Is clone a valid quick fix for E0382?

Clone can be valid if the type is cheap to clone or you need independent ownership, but overusing clone hides design issues—prefer clear ownership or shared smart pointers when appropriate.

How do I choose between Rc/RefCell and Arc/Mutex?

Use Rc/RefCell for single-threaded shared ownership with interior mutability. Use Arc plus Mutex/RwLock for multi-threaded sharing and thread-safe interior mutability; prefer the simpler choice when concurrency isn't required.