大規模 Rust コード生成スキル · 大规模 Rust 代码生成技能 · 大規模 Rust 程式碼生成技能 · Habilidad de generación de Rust a gran escala
| English | 日本語 | 简体中文 | 繁體中文 | Español |
|---|
Rust Safe Large is a hardened skill for large-scale Rust code generation and language ports (e.g., Zig → Rust, C → Rust, C++ → Rust). It is designed to prevent the major failure modes seen in large AI-generated Rust codebases.
This skill is informed by analysis of real-world large-scale Rust ports, most notably Bun's Zig-to-Rust rewrite (PR #30412: 1M+ additions, 2188 files, 6755 commits, 698 comments), and the regressions that followed.
Key issues observed in Bun's Rust port:
- Post-port regressions — Multiple regressions tracked in Issue #31477, including asset path handling, Windows-specific bugs, and runtime errors
- TODO/PORT backlog accumulation — Unfinished port work left as TODOs (
TODO(port),TODO(b2),PORT NOTE) created long-running technical debt - Non-idiomatic pattern carryover — Zig idioms (e.g., boolean comparison patterns) carried into the Rust codebase without idiomatic conversion
- Large-scale unsafe management — Extensive
unsafeusage required for performance, making Miri verification and soundness auditing critical - FFI boundary complexity — JavaScriptCore C API bindings requiring careful safe abstraction layers
- State machine translation gaps — Zig comptime + switch dispatch patterns not cleanly mapping to Rust's type system
- Platform-specific breakage — Regressions on Windows and other platforms surfaced only after the port landed
This skill's mandatory LeftShift, phased generation, unsafe decision framework, and Miri verification are all designed to prevent these exact failure modes.
- Large feature additions to existing projects
- Full module or subsystem rewrites
- Language ports (Zig, C, C++ → Rust)
- Any Rust task exceeding ~500 lines or spanning multiple modules
Note: For small to medium tasks (single module, < ~500 lines, localized changes), consider a lighter workflow instead.
Step 0: Aggressive LeftShift (Deep Requirement + Project Analysis)
↓
Phase 1: Strict Prevention + Phased Generation
↓
Phase 2: Deep Treatment + Soundness Focus
↓
Phase 3: Verification (Compile + Test + Clippy + Miri) ← Enhanced
↓
Human Review Checkpoint (for critical parts)
↓
Final Output (includes design rationale + module map)
Deep clarification before generating code. Analyzes:
- Unsafe usage — how much exists, why, and past issues
- Module architecture — dependency graph, circular deps, public API surface
- Problematic patterns — raw pointers, manual resource management
- Error handling — error types, cleanup strategies
- Architectural constraints — ownership model compatibility, build times
- Existing tests — infrastructure, coverage, property-based tests
- Language port specifics — source language, memory model, FFI boundaries
Unsafe Decision Framework — Before using any unsafe:
- Is
unsafetruly necessary? (List 2-3 safe alternatives first) - Can the scope be minimized?
- What invariants must hold for soundness?
- How will invariants be documented and enforced?
Phased Generation — Generate one module at a time in dependency order (leaf → root). Run cargo check after each module.
Priority refactoring targets:
- Unsafe — Remove unnecessary
unsafe, fix unsound safe APIs - Ownership — Reduce excessive
.clone(), improveArc<Mutex<T>>usage - Idiomatic Rust — State machines →
enum+match, useDrop, iterators - Error handling — Remove
.unwrap(), introducethiserror/anyhow
| Step | Command | Description |
|---|---|---|
| 1 | cargo check |
Compile check — fix first error first |
| 2 | cargo test |
Test execution — add tests for new code |
| 3 | cargo clippy -- -D warnings |
Lint check — fix all warnings |
| 4 | cargo test --doc |
Doc tests (if library) |
| 5 | cargo miri test |
UB check (if unsafe present) |
Strongly recommended for:
- Introduction of new
unsafecode - Significant architectural changes
- Modification of existing unsafe API contracts
- Modules that failed Miri checks
- Language port critical paths
Each generation includes:
- LeftShift Summary — Task answers, project findings, module dependency map
- Generation Strategy — Unsafe decisions, phased approach, dependency order
- Key Improvements — Unsafe removed, soundness fixes, refactoring
- Verification Results — PASS/FAIL for each verification step
- Design Rationale — Key decisions, alternatives considered, trade-offs
- Soundness Notes — Miri results, safety invariants
- Areas Requiring Human Review
- Test Coverage Summary
- Final Code + Recommendations
| Source Pattern | Rust Target | Notes |
|---|---|---|
malloc/free |
Box<T>, Vec<T>, alloc::alloc |
Use Box for single objects, Vec for arrays |
| Arena allocator | typed_arena::Arena, bumpalo |
Consider existing crates before custom allocator |
| Reference counting | Arc<T>, Rc<T> |
Match ownership semantics carefully |
| Raw pointer chains | &/&mut references, Pin<Box<T>> |
Redesign ownership graph if needed |
Rust Safe Large は、大規模な Rust コード生成 および 言語移植（Zig → Rust、C → Rust、C++ → Rust など） のために設計された高堅牢化スキルです。大規模な AI 生成 Rust コードベースで見られる主要な障害モードを防止することを目的としています。
本スキルは、Bun（Zig 製 JavaScript ランタイム）の大規模 Rust 移植（PR #30412：100万行超、2188ファイル、6755コミット、698コメント）で実際に発生した問題点を分析・予防するように設計されています。
Bun の Rust 移植で確認された主な問題:
- 移植後リグレッション — 移植後に多数のリグレッションが発生（Issue #31477 で継続追跡）
- TODO/PORT バックログの蓄積 — 移植作業の未完了部分が
TODO(port)/TODO(b2)/PORT NOTEとして残り、長期的な技術負債に - 非慣用的なパターンの持ち越し — Zig 由来の非慣用的なコードパターン（真偽値比較など）が Rust 側にそのまま残存
- 大規模 unsafe コードの管理 — パフォーマンス要件から unsafe の多用が必要となり、Miri 検証と安全性監査がクリティカルに
- FFI 境界の複雑さ — JavaScriptCore C API バインディングの安全な抽象化レイヤの設計が困難
- 状態機械変換のギャップ — Zig の comptime + switch ディスパッチから Rust の型システムへのマッピングが不整合を起こす
- プラットフォーム固有のバグ — Windows など一部プラットフォームで移植後に初めて顕在化するバグ
本スキルの LeftShift 分析、段階的生成、unsafe 判断フレームワーク、Miri 検証は、これらの障害モードを正確に予防するように設計されています。
- 既存プロジェクトへの大規模機能追加
- モジュール全体またはサブシステムの書き換え
- 言語移植（Zig、C、C++ → Rust）
- 約500行以上、または複数モジュールにまたがる Rust タスク
注意: 小〜中規模タスク（単一モジュール、500行未満、局所的な変更）の場合は、より軽量なワークフローの使用を検討してください。
Step 0: 積極的な LeftShift（深い要件分析＋プロジェクト分析）
↓
Phase 1: 厳格な予防 + 段階的生成
↓
Phase 2: 深い処理 + 健全性（Soundness）重視
↓
Phase 3: 検証（コンパイル + テスト + Clippy + Miri）← 強化版
↓
人間によるレビューチェックポイント（重要部分）
↓
最終出力（設計根拠 + モジュールマップを含む）
コード生成前に深い明確化を実施。以下の分析を行います：
- unsafe の使用状況 — 使用量、理由、過去の問題
- モジュールアーキテクチャ — 依存関係グラフ、循環依存、公開API
- 問題のあるパターン — 生ポインタ、手動リソース管理
- エラーハンドリング — エラータイプ、クリーンアップ戦略
- アーキテクチャ上の制約 — 所有権モデルの互換性、ビルド時間
- 既存テスト — テスト基盤、カバレッジ、プロパティベーステスト
- 言語移植の詳細 — ソース言語、メモリモデル、FFI境界
Unsafe 判断フレームワーク — unsafe を使用する前に:
unsafeは本当に必要か？（最初に2〜3の安全な代替案を列挙）- スコープを最小化できるか？
- 健全性のためにどのような不変条件が成立する必要があるか？
- それらの不変条件はどのように文書化・強制されるか？
段階的生成 — 依存関係順（葉→ルート）で一度に1つのモジュールを生成。各モジュール後に cargo check を実行。
優先リファクタリング対象：
- Unsafe — 不要な
unsafeの削除、安全でない安全APIの修正 - 所有権 — 過剰な
.clone()の削減、Arc<Mutex<T>>の改善 - 慣用的な Rust — ステートマシン →
enum+match、Dropの活用、イテレータ - エラーハンドリング —
.unwrap()の除去、thiserror/anyhowの導入
| ステップ | コマンド | 説明 |
|---|---|---|
| 1 | cargo check |
コンパイルチェック — 最初のエラーから修正 |
| 2 | cargo test |
テスト実行 — 新しいコードにテストを追加 |
| 3 | cargo clippy -- -D warnings |
リントチェック — すべての警告を修正 |
| 4 | cargo test --doc |
ドキュメントテスト（ライブラリの場合） |
| 5 | cargo miri test |
UB チェック（unsafe が存在する場合） |
以下の場合に強く推奨：
- 新しい
unsafeコードの導入 - 重要なアーキテクチャ変更
- 既存の unsafe API コントラクトの変更
- Miri チェックに失敗したモジュール
- 言語移植のクリティカルパス
各生成には以下を含みます：
- LeftShift サマリー — タスク回答、プロジェクト調査結果、モジュール依存関係マップ
- 生成戦略 — Unsafe 判断、段階的アプローチ、依存関係順序
- 主な改善点 — 削除された Unsafe、健全性修正、リファクタリング
- 検証結果 — 各検証ステップの PASS/FAIL
- 設計根拠 — 主要な決定、検討した代替案、トレードオフ
- 健全性ノート — Miri 結果、安全不変条件
- 人間によるレビューが必要な領域
- テストカバレッジサマリー
- 最終コード + 推奨事項
| ソースパターン | Rust ターゲット | 備考 |
|---|---|---|
malloc/free |
Box<T>, Vec<T>, alloc::alloc |
単一オブジェクトは Box、配列は Vec |
| アリーナアロケータ | typed_arena::Arena, bumpalo |
カスタムアロケータより既存クレートを優先 |
| 参照カウント | Arc<T>, Rc<T> |
所有権セマンティクスを慎重に一致させる |
| 生ポインタチェーン | &/&mut 参照, Pin<Box<T>> |
必要に応じて所有権グラフを再設計 |
Rust Safe Large 是一个强化版的 大规模 Rust 代码生成 和 语言移植（如 Zig → Rust、C → Rust、C++ → Rust） 技能。它旨在防止大型 AI 生成的 Rust 代码库中常见的重大故障模式。
本技能基于真实世界的大规模 Rust 移植案例——特别是 Bun 的 Zig 到 Rust 重写（PR #30412：100万+ 新增代码、2188 文件、6755 提交、698 评论）及其后续回归问题进行分析设计。
Bun 的 Rust 移植中观察到的主要问题:
- 移植后回归 — 多个回归问题在 Issue #31477 中持续追踪，包括资产路径处理、Windows 特定错误和运行时问题
- TODO/PORT 积压积累 — 未完成的移植工作以
TODO(port)/TODO(b2)/PORT NOTE形式留下，形成长期技术债务 - 非惯用模式遗留 — Zig 的习惯用法（如布尔比较模式）未经过惯用转换就被带入 Rust 代码库
- 大规模 unsafe 管理 — 性能需求导致大量
unsafe使用，使 Miri 验证和健全性审计变得至关重要 - FFI 边界复杂性 — JavaScriptCore C API 绑定需要精心设计安全抽象层
- 状态机转换差距 — Zig 的 comptime + switch 分发模式无法干净地映射到 Rust 的类型系统
- 平台特定问题 — 仅在移植完成后才在 Windows 等平台上暴露的回归问题
本技能强制要求的 LeftShift 分析、分阶段生成、unsafe 决策框架和 Miri 验证都是为了精确预防这些故障模式而设计的。
- 为现有项目添加大型功能
- 完整模块或子系统的重写
- 语言移植（Zig、C、C++ → Rust）
- 任何超过约 500 行或跨多个模块的 Rust 任务
注意： 对于中小型任务（单一模块、少于 500 行、局部变更），请考虑使用更轻量的工作流。
Step 0: 激进式 LeftShift（深度需求分析 + 项目分析）
↓
Phase 1: 严格预防 + 分阶段生成
↓
Phase 2: 深度处理 + 安全性（Soundness）聚焦
↓
Phase 3: 验证（编译 + 测试 + Clippy + Miri）← 增强版
↓
人工审查节点（关键部分）
↓
最终输出（包含设计原理 + 模块映射）
在生成代码之前进行深度澄清。分析内容包括：
- unsafe 使用情况 — 使用量、原因、过去的问题
- 模块架构 — 依赖关系图、循环依赖、公开 API
- 问题模式 — 原始指针、手动资源管理
- 错误处理 — 错误类型、清理策略
- 架构约束 — 所有权模型兼容性、构建时间
- 现有测试 — 基础设施、覆盖率、基于属性的测试
- 语言移植细节 — 源语言、内存模型、FFI 边界
Unsafe 决策框架 — 在使用任何 unsafe 之前：
unsafe是否真的必要？（先列出 2-3 个安全替代方案）- 能否最小化作用域？
- 为保证安全性需要满足哪些不变量？
- 这些不变量将如何被文档化和强制执行？
分阶段生成 — 按依赖顺序（叶 → 根）一次生成一个模块。每个模块后运行 cargo check。
优先重构目标：
- Unsafe — 删除不必要的
unsafe，修复不安全的 API - 所有权 — 减少过多的
.clone()，改进Arc<Mutex<T>>使用 - 地道 Rust — 状态机 →
enum+match，使用Drop、迭代器 - 错误处理 — 移除
.unwrap()，引入thiserror/anyhow
| 步骤 | 命令 | 说明 |
|---|---|---|
| 1 | cargo check |
编译检查 — 从第一个错误开始修复 |
| 2 | cargo test |
测试执行 — 为新代码添加测试 |
| 3 | cargo clippy -- -D warnings |
Lint 检查 — 修复所有警告 |
| 4 | cargo test --doc |
文档测试（如果是库） |
| 5 | cargo miri test |
未定义行为检查（如果使用了 unsafe） |
强烈建议在以下情况下进行人工审查：
- 引入新的
unsafe代码 - 重大架构变更
- 修改现有 unsafe API 契约
- 未通过 Miri 检查的模块
- 语言移植的关键路径
每次生成包含：
- LeftShift 总结 — 任务答案、项目发现、模块依赖图
- 生成策略 — Unsafe 决策、分阶段方法、依赖顺序
- 主要改进 — 移除的 Unsafe、安全性修复、重构
- 验证结果 — 每个验证步骤的 PASS/FAIL
- 设计原理 — 关键决策、考虑的替代方案、权衡
- 安全性说明 — Miri 结果、安全不变量
- 需要人工审查的领域
- 测试覆盖总结
- 最终代码 + 建议
| 源模式 | Rust 目标 | 说明 |
|---|---|---|
malloc/free |
Box<T>, Vec<T>, alloc::alloc |
单一对象用 Box，数组用 Vec |
| 区域分配器 | typed_arena::Arena, bumpalo |
优先使用现有 crate 而非自定义分配器 |
| 引用计数 | Arc<T>, Rc<T> |
谨慎匹配所有权语义 |
| 原始指针链 | &/&mut 引用, Pin<Box<T>> |
如有必要重新设计所有权图 |
Rust Safe Large 是一個強化版的 大規模 Rust 程式碼生成 和 語言移植（如 Zig → Rust、C → Rust、C++ → Rust） 技能。它旨在防止大型 AI 生成的 Rust 程式碼庫中常見的重大故障模式。
本技能基於真實世界的大規模 Rust 移植案例——特別是 Bun 的 Zig 到 Rust 重寫（PR #30412：100萬+ 新增程式碼、2188 檔案、6755 提交、698 評論）及其後續回歸問題進行分析設計。
Bun 的 Rust 移植中觀察到的主要問題:
- 移植後回歸 — 多個回歸問題在 Issue #31477 中持續追蹤，包括資產路徑處理、Windows 特定錯誤和執行時期問題
- TODO/PORT 積壓積累 — 未完成的移植工作以
TODO(port)/TODO(b2)/PORT NOTE形式留下，形成長期技術債務 - 非慣用模式遺留 — Zig 的習慣用法（如布林比較模式）未經過慣用轉換就被帶入 Rust 程式碼庫
- 大規模 unsafe 管理 — 效能需求導致大量
unsafe使用，使 Miri 驗證和健全性審計變得至關重要 - FFI 邊界複雜性 — JavaScriptCore C API 綁定需要精心設計安全抽象層
- 狀態機轉換差距 — Zig 的 comptime + switch 分發模式無法乾淨地映射到 Rust 的型別系統
- 平台特定問題 — 僅在移植完成後才在 Windows 等平台上暴露的回歸問題
本技能強制要求的 LeftShift 分析、分階段生成、unsafe 決策框架和 Miri 驗證都是為了精確預防這些故障模式而設計的。
- 為現有專案添加大型功能
- 完整模組或子系統的重寫
- 語言移植（Zig、C、C++ → Rust）
- 任何超過約 500 行或跨越多個模組的 Rust 任務
注意： 對於中小型任務（單一模組、少於 500 行、局部變更），請考慮使用更輕量的工作流程。
Step 0: 激進式 LeftShift（深度需求分析 + 專案分析）
↓
Phase 1: 嚴格預防 + 分階段生成
↓
Phase 2: 深度處理 + 健全性（Soundness）聚焦
↓
Phase 3: 驗證（編譯 + 測試 + Clippy + Miri）← 增強版
↓
人工審查節點（關鍵部分）
↓
最終輸出（包含設計原理 + 模組映射）
在生成程式碼之前進行深度釐清。分析內容包括：
- unsafe 使用情況 — 使用量、原因、過去的問題
- 模組架構 — 依賴關係圖、循環依賴、公開 API
- 問題模式 — 原始指標、手動資源管理
- 錯誤處理 — 錯誤類型、清理策略
- 架構約束 — 所有權模型相容性、建置時間
- 現有測試 — 基礎設施、覆蓋率、基於屬性的測試
- 語言移植細節 — 來源語言、記憶體模型、FFI 邊界
Unsafe 決策框架 — 在使用任何 unsafe 之前：
unsafe是否真的必要？（先列出 2-3 個安全替代方案）- 能否最小化作用域？
- 為保證健全性需要滿足哪些不變量？
- 這些不變量將如何被文件化和強制執行？
分階段生成 — 按依賴順序（葉 → 根）一次產生一個模組。每個模組後執行 cargo check。
優先重構目標：
- Unsafe — 刪除不必要的
unsafe，修復不安全的 API - 所有權 — 減少過多的
.clone()，改進Arc<Mutex<T>>使用 - 慣用 Rust — 狀態機 →
enum+match，使用Drop、迭代器 - 錯誤處理 — 移除
.unwrap()，引入thiserror/anyhow
| 步驟 | 命令 | 說明 |
|---|---|---|
| 1 | cargo check |
編譯檢查 — 從第一個錯誤開始修復 |
| 2 | cargo test |
測試執行 — 為新程式碼添加測試 |
| 3 | cargo clippy -- -D warnings |
Lint 檢查 — 修復所有警告 |
| 4 | cargo test --doc |
文件測試（如果是函式庫） |
| 5 | cargo miri test |
未定義行為檢查（如果使用了 unsafe） |
強烈建議在以下情況下進行人工審查：
- 引入新的
unsafe程式碼 - 重大架構變更
- 修改現有 unsafe API 契約
- 未通過 Miri 檢查的模組
- 語言移植的關鍵路徑
每次生成包含：
- LeftShift 總結 — 任務答案、專案發現、模組依賴圖
- 生成策略 — Unsafe 決策、分階段方法、依賴順序
- 主要改進 — 移除的 Unsafe、健全性修復、重構
- 驗證結果 — 每個驗證步驟的 PASS/FAIL
- 設計原理 — 關鍵決策、考慮的替代方案、權衡
- 健全性說明 — Miri 結果、安全不變量
- 需要人工審查的領域
- 測試覆蓋總結
- 最終程式碼 + 建議
| 來源模式 | Rust 目標 | 備註 |
|---|---|---|
malloc/free |
Box<T>, Vec<T>, alloc::alloc |
單一物件用 Box，陣列用 Vec |
| 區域分配器 | typed_arena::Arena, bumpalo |
優先使用現有 crate 而非自訂分配器 |
| 引用計數 | Arc<T>, Rc<T> |
謹慎匹配所有權語意 |
| 原始指標鏈 | &/&mut 引用, Pin<Box<T>> |
如有必要重新設計所有權圖 |
Rust Safe Large es una habilidad robusta para la generación de código Rust a gran escala y portabilidad de lenguajes (p. ej., Zig → Rust, C → Rust, C++ → Rust). Está diseñada para prevenir los principales modos de fallo observados en grandes bases de código Rust generadas por IA.
Esta habilidad se basa en el análisis de casos reales de portabilidad de Rust a gran escala, especialmente la reescritura de Bun de Zig a Rust (PR #30412: 1M+ adiciones, 2188 archivos, 6755 commits, 698 comentarios) y las regresiones que le siguieron.
Problemas clave observados en la portabilidad de Bun a Rust:
- Regresiones post-portabilidad — Múltiples regresiones rastreadas en Issue #31477, incluyendo manejo de rutas de assets, errores específicos de Windows y errores en tiempo de ejecución
- Acumulación de backlog TODO/PORT — Trabajo de portabilidad incompleto dejado como
TODO(port)/TODO(b2)/PORT NOTEcreando deuda técnica a largo plazo - Arrastre de patrones no idiomáticos — Modismos de Zig (ej. patrones de comparación booleana) trasladados al código Rust sin conversión idiomática
- Gestión de unsafe a gran escala — Uso extensivo de
unsaferequerido por rendimiento, haciendo crítica la verificación con Miri y la auditoría de solidez - Complejidad de límites FFI — Bindings de la API C de JavaScriptCore que requieren cuidadosas capas de abstracción segura
- Brechas en traducción de máquinas de estado — Patrones de dispatch comptime + switch de Zig que no se mapean limpiamente al sistema de tipos de Rust
- Roturas específicas de plataforma — Regresiones en Windows y otras plataformas que solo aparecieron después de que la portabilidad se completó
El LeftShift obligatorio, la generación por fases, el marco de decisión de unsafe y la verificación con Miri de esta habilidad están diseñados para prevenir exactamente estos modos de fallo.
- Adiciones de funciones grandes a proyectos existentes
- Reescrituras completas de módulos o subsistemas
- Portabilidad de lenguajes (Zig, C, C++ → Rust)
- Cualquier tarea de Rust que supere ~500 líneas o abarque múltiples módulos
Nota: Para tareas pequeñas o medianas (módulo único, < ~500 líneas, cambios localizados), considere usar un flujo de trabajo más ligero.
Paso 0: LeftShift Agresivo (Análisis Profundo de Requisitos + Proyecto)
↓
Fase 1: Prevención Estricta + Generación por Fases
↓
Fase 2: Tratamiento Profundo + Enfoque en Solidez (Soundness)
↓
Fase 3: Verificación (Compilar + Probar + Clippy + Miri) ← Mejorado
↓
Punto de Control de Revisión Humana (para partes críticas)
↓
Salida Final (incluye fundamentos de diseño + mapa de módulos)
Aclaración profunda antes de generar código. Analiza:
- Uso de unsafe — cuánto existe, por qué y problemas pasados
- Arquitectura de módulos — grafo de dependencias, dependencias circulares, API pública
- Patrones problemáticos — punteros crudos, gestión manual de recursos
- Manejo de errores — tipos de error, estrategias de limpieza
- Restricciones arquitectónicas — compatibilidad con el modelo de propiedad, tiempos de compilación
- Pruebas existentes — infraestructura, cobertura, pruebas basadas en propiedades
- Detalles de portabilidad — lenguaje fuente, modelo de memoria, límites FFI
Marco de Decisión para Unsafe — Antes de usar cualquier unsafe:
- ¿Es realmente necesario
unsafe? (Enumere 2-3 alternativas seguras primero) - ¿Se puede minimizar el alcance?
- ¿Qué invariantes deben cumplirse para la solidez?
- ¿Cómo se documentarán y aplicarán estas invariantes?
Generación por Fases — Genere un módulo a la vez en orden de dependencias (hoja → raíz). Ejecute cargo check después de cada módulo.
Objetivos prioritarios de refactorización:
- Unsafe — Eliminar
unsafeinnecesario, corregir APIs inseguras - Propiedad — Reducir
.clone()excesivo, mejorar uso deArc<Mutex<T>> - Rust idiomático — Máquinas de estado →
enum+match, usarDrop, iteradores - Manejo de errores — Eliminar
.unwrap(), introducirthiserror/anyhow
| Paso | Comando | Descripción |
|---|---|---|
| 1 | cargo check |
Verificación de compilación — corregir primer error |
| 2 | cargo test |
Ejecución de pruebas — agregar pruebas para código nuevo |
| 3 | cargo clippy -- -D warnings |
Verificación de lint — corregir todas las advertencias |
| 4 | cargo test --doc |
Pruebas de documentación (si es biblioteca) |
| 5 | cargo miri test |
Verificación de UB (si hay unsafe) |
Altamente recomendado para:
- Introducción de nuevo código
unsafe - Cambios arquitectónicos significativos
- Modificación de contratos de API unsafe existentes
- Módulos que fallaron las verificaciones de Miri
- Rutas críticas de portabilidad de lenguaje
Cada generación incluye:
- Resumen de LeftShift — Respuestas de tarea, hallazgos del proyecto, mapa de dependencias
- Estrategia de Generación — Decisiones sobre Unsafe, enfoque por fases, orden de dependencias
- Mejoras Clave — Unsafe eliminado, correcciones de solidez, refactorización
- Resultados de Verificación — PASS/FAIL para cada paso
- Fundamentos de Diseño — Decisiones clave, alternativas consideradas, compensaciones
- Notas de Solidez — Resultados de Miri, invariantes de seguridad
- Áreas que Requieren Revisión Humana
- Resumen de Cobertura de Pruebas
- Código Final + Recomendaciones
| Patrón Fuente | Destino en Rust | Notas |
|---|---|---|
malloc/free |
Box<T>, Vec<T>, alloc::alloc |
Use Box para objetos únicos, Vec para arreglos |
| Asignador de arena | typed_arena::Arena, bumpalo |
Considere crates existentes antes que asignador personalizado |
| Conteo de referencias | Arc<T>, Rc<T> |
Iguale semántica de propiedad cuidadosamente |
| Cadenas de punteros crudos | Referencias &/&mut, Pin<Box<T>> |
Rediseñe el grafo de propiedad si es necesario |
MIT