Rust 2025H2 Project Goals 最終進度：Pin 人體工學、build-std 與 Const Generics
Rust Blog · 2026-05-18
Rust 專案官方發布了 2025H2 Project Goals 的四月進度總結，此期目標週期正式結束。共追蹤 41 個 Project Goals，其中 13 個為 Flagship Goals。多數旗艦目標標記為「Continued」，代表將延伸進入 2026 年規劃週期；少數因資金或人力問題停滯。
核心改動
Pin Ergonomics（Frank King 主導）取得具體進展：已實作 &pin 類型與普通引用之間的強制轉換，適用於實作 Unpin 的類型；borrowck 實作已進行中，但遭遇區分 pinned borrows 與 coercions 的問題，尚未解決。Field Projections 方面，實驗性 field_of! macro 已合併，t-lang 設計會議反應「極為正面」，形式模型仍在開發中。
build-std（David Wood 主導）持續推進：RFC #3874 已完成 FCP，RFC #3875 在審查中，Cargo 實作 PR #16675 進入早期開發。Cranelift Backend 則因「資金不足」停滯，明確標注「未完成」。
Next-Generation Trait Solver（lcnr 主導）持續進行：Nicholas Nethercote 改善效能，crater 測試正在進行，多項推論與 auto trait 合成改進持續合入。Stabilizable Polonius 進度良好，PR #150551 已落地並被認定「可穩定化」，團隊計畫在 2026 年完成穩定化；opaque type region liveness soundness 問題追蹤於 #153215。
C++/Rust 互操作
C++/Rust Interop 問題空間映射已識別兩個高優先用例：函數重載（overloading）與建構系統整合。語言端的重載實驗 PR #153697 正在進行，已完成兩輪審查。Const Generics 方面，min_generic_const_args 已與 associated_const_equality 合併，多種表達式類型現在支援 const generic 引數。
影響範圍
對 Rust 使用者而言，多數改動仍在 nightly 或實驗性功能旗標後面。Polonius 的穩定化計畫是 2026 年最具影響力的潛在改動，它將解除部分目前 borrow checker 因過度保守而拒絕的合法程式碼。Cargo-script 的 FCP 進展也意味著穩定的腳本執行支援離正式發布不遠。
原始來源：Rust Blog
Go 1.26 型別建構與循環偵測：修復隱藏多年的編譯器 Panic
Go Blog · 2026-03-24
Go 1.26 對型別檢查器的型別建構（type construction）與循環偵測（cycle detection）演算法進行了系統性重寫，修復了 #75918、#76383、#76384、#76478 等多個導致編譯器 panic 的邊界情況。改動對一般 Go 程式碼不可見，但為未來型別系統功能的開發奠定更穩固的基礎。
背景
Go 型別建構將 AST 的型別表達式轉換為內部的 Defined、Slice、Pointer、Array 等型別結構。型別的「完成」遵循深度優先順序——一個型別只有在其所有依賴的型別完成後才能完成。Go 允許透過指標形成遞迴型別，例如 type Node struct { next *Node }；這種情況下，型別建構器在遭遇未完成型別時直接指向它，假設它稍後會完成，形成一個環狀完成關係。
核心改動
問題出現在型別建構過程中需要「解構（deconstruct）」一個未完成型別時。以下是典型的循環錯誤情境：
type T [unsafe.Sizeof(T{})]int // 編譯錯誤：循環
// T 需要 Array 完成 → Array 需要知道 T 的大小 → 需要解構 T → T 未完成對比合法的遞迴用法：
type T [unsafe.Sizeof(new(T))]int // 合法
// new(T) 只需指標大小，不需解構 T 本身新實作在每個可能產生「未完成值」的上游表達式（轉換、函數呼叫、型別斷言、channel 接收、map 存取、dereference）前插入完整性檢查，在值往下游傳播（可能被解構的地方）之前驗證型別是否已完成，若未完成則報告循環錯誤並終止。
影響範圍
這是純粹的正確性修復，不帶任何 API 變更。對於一般 Go 程式碼完全無感；受影響的是那些使用 unsafe.Sizeof、unsafe.Alignof 等在陣列大小表達式中引用自身型別的複雜定義——這類程式碼原本可能導致編譯器崩潰，現在會正確報告錯誤。
原始來源：Go Blog
Linux 7.1-rc5：Linus Torvalds 警告 AI 程式碼審查引發的無效修補潮
LWN.net · 2026-05-24
Linus Torvalds 在 Linux 7.1-rc5 發布公告中表達對這個 RC 版本異常龐大的擔憂，並點名部分提交是由 AI 程式碼審查工具觸發的低優先級修補。他明確表示，在發布週期後期合入對長期存在問題的非關鍵性修復是不適切的，並宣布將加強對這類 pull request 的審查力道。
rc5 的規模問題
Torvalds 指出：「rc5 相當龐大。比歷史上的 rc5 都大很多。」RC5 包含超過 1,000 個個別修補，涵蓋驅動程式、檔案系統、網路（batman-adv、netfilter、MPTCP）、ARM/GPU 驅動及安全更新——大部分是邊界情況與細節修正，而非關鍵性回歸修復。這個規模在 RC5 階段本不應出現。
AI 審查觸發的問題
Torvalds 直接承認：「是的，這些系列中有幾個是由 AI 程式碼審查觸發的。」他的核心論點是，AI 工具識別出潛在問題後，維護者急於在當前週期修補，即使這些問題長期存在且不緊急。他要求維護者自問：「這真的是回歸或嚴重到不能等到下個開發週期再修？」
他宣布的應對策略是：對「修改沒那麼重要的無意義 pull request」採取更強硬的態度，直接拒絕。核心原則是 RC 週期應聚焦於回歸修復，不是例行改進。
影響範圍
這是一個關於 AI 工具如何改變核心開發文化的明確訊號。AI 程式碼審查工具在靜態分析方面確實有效，但它們無法判斷「現在修」還是「下個週期修」哪個更合適——這是人類工程判斷力的範疇。Torvalds 的公開表態意味著未來由 AI 審查觸發的後期修補將面臨更嚴格的審查，這也將影響各大發行版的 patch 策略。
原始來源：LWN.net