後端工坊 2026 年 5 月 19 日

2026-05-19 — Fil-C 呼叫慣例最佳化、cargo-crap CRAP 指標、Rust Polonius alpha 可穩定

primary=https://fil-c.org/calling_convention primary=https://minikin.me/blog/cargo-crap/ primary=https://blog.rust-lang.org/2026/05/18/project-goals-2026-04/

Fil-C 最佳化呼叫慣例:以暫存器傳遞與 64-bit 簽名編碼突破記憶體安全 C/C++ 的呼叫效能

fil-c.org · 2026-05-19

Fil-C 是一個為 C/C++ 提供記憶體安全保證的編譯器框架。為了在安全驗證的前提下維持原生呼叫效能,Fil-C 發布了最佳化呼叫慣例的詳細設計文件,說明如何以三層機制解決函式呼叫的型別安全驗證開銷。

背景

記憶體安全 C/C++ 框架的核心挑戰在於每次函式呼叫都必須驗證呼叫端與被呼叫端的簽名相符,以防止型別混淆攻擊。傳統做法是透過執行緒區域緩衝區(thread-local buffer)傳遞參數,但這引入了顯著的記憶體存取開銷。Fil-C 的最佳化目標是:在合法呼叫路徑上完全消除這個開銷,僅在真正的簽名不符時才退回到安全但較慢的路徑。

規格細節

第一層:暫存器呼叫慣例。取代透過記憶體緩衝區傳遞參數,Fil-C 改用原生暫存器呼叫慣例。每個函式物件儲存其簽名的 64-bit 算術編碼。呼叫前比對呼叫端期望的簽名與被呼叫函式的簽名;相符時直接使用快速進入點,不符時則觸發 thunk 在通用緩衝區路徑間轉換。

第二層:算術簽名編碼。支援最多 16 個參數與 2 個回傳值,跨整數、浮點、向量、指標型別的簽名壓縮為 64-bit 整數,公式為:

signature = 1 + Ret + Arg × 133

其中 RetArg 為對應型別序列的編碼值。這讓簽名比較無需任何中介資料查詢。

第三層:直接呼叫最佳化。對於靜態已知目標的直接呼叫,編譯器直接發出對 mangled 實作符號的呼叫,而非透過 getter 函式與能力檢查解析。「known target callsite thunk」以 ELF weak symbol 搭配 COMDAT 實現,確保簽名不符時的回退路徑正確運作,且不造成無限迴圈。

影響範圍

在 PizBench9019 基準上,暫存器呼叫慣例最佳化帶來 >1% 加速;直接呼叫最佳化另外帶來 >1% 加速。雖然數字看似不大,但在高呼叫密度的 C++ 程式中(物件方法、虛擬呼叫鏈)效果會累積。Fil-C 的整體目標是讓記憶體安全 C/C++ 的執行效能接近原生未保護程式碼,這三層最佳化是達成此目標的關鍵路徑。

原始來源:Fil-C 官方技術文件


cargo-crap:以 CRAP 指標量化 AI 生成 Rust 程式碼的未測試複雜度

minikin.me · 2026-05-19

cargo-crap 是一個 Rust 工具,用於識別同時具有高複雜度且測試覆蓋不足的函式。它採用源自 2007 年的 CRAP(Change Risk Anti-Patterns)指標,將環形複雜度(cyclomatic complexity)與測試覆蓋率結合成單一風險分數,專門針對 AI 輔助開發場景中大量生成但測試稀少的程式碼。

核心改動

CRAP 公式同時懲罰高複雜度與低覆蓋率:

CRAP(m) = comp(m)² × (1 − cov(m)/100)³ + comp(m)

其中 comp(m) 為函式的環形複雜度,cov(m) 為測試覆蓋百分比(0–100)。當一個函式完全未覆蓋(cov=0)時,公式簡化為 comp² + comp;當完全覆蓋(cov=100)時,簡化為 comp。這個設計讓「簡單但未測試」的函式分數合理偏低,而「複雜且未測試」的函式分數快速膨脹。

預設閾值為 30,超過此值的函式會被標記為需要關注。工具可整合進 CI/CD 管線,支援絕對閾值強制(新專案)或基線比較(現有程式碼庫避免退化)兩種模式。

為什麼是 AI 生成程式碼的問題

AI 程式碼生成工具傾向於產生表面功能正確但缺乏測試的實作。覆蓋率單獨衡量不夠——一個簡單的未測試函式風險遠低於一個有複雜邏輯分支但無測試的函式。CRAP 指標正是為了捕捉這個「未測試複雜度」的核心風險:程式碼在未來修改時最容易引入 regression 的地方。

影響範圍

cargo-crap 依賴標準 cargo test --coverage 輸出。在 CI 中執行的基本用法是設定失敗閾值,確保新合併的程式碼(無論是人工還是 AI 生成)不會帶入過高風險的未測試複雜度。作者特別指出,這個工具的設計哲學是提供可量化的防護措施,而非主觀的程式碼品質評判。

原始來源:minikin.me


Rust 2026H2 專案目標四月進度:Polonius alpha 達可穩定門檻、field_of! 巨集合併主線

Rust Blog · 2026-05-18

Rust 專案團隊發布 2025H2 目標期間的四月進度更新,涵蓋 41 個專案目標(含 13 個旗艦計畫)。本次更新最值得關注的技術進展集中在借用檢查器、型別系統與編譯效能三個方向。

核心改動

Polonius 新一代借用檢查器達到 alpha 可穩定門檻。Polonius 解決了舊版 NLL(Non-Lexical Lifetimes)無法處理的部分「回傳後使用同一可變借用」模式,PR #150551 已合併,標誌著從研究原型到可供用戶嘗試的階段過渡完成。

field_of! 巨集(field projections 提案)由 Benno Lossin 實作並合併,提供透過型別層級表示操作結構體欄位的安全方式。此功能對需要在 Pin<T>MaybeUninit<T> 中安全存取欄位的場景尤為關鍵。

Const generics 形式化透過 a-mir-formality 工具加速進行,以純量值(scalar)與剛性值(rigid value)表示 const 值的完整建模已推進。C++/Rust 互操作性計畫則確認了高優先度的用例,包括呼叫 C++ 重載函式(overloaded function)的實作路徑。

其他進展

  • Build-std RFC:進入最終反饋階段,將允許在穩定工具鏈中建置標準函式庫
  • Ergonomic ref-counting RFC:決策待審,目標減少 Rc::clone() 的語法噪音
  • Cargo-script 穩定化:FCP 接近關閉,允許直接執行 .rs 腳本
  • BorrowSanitizer:從研究原型演進至功能性工具,在 Miri 測試中達到 80% 通過率
  • Cranelift 後端:因資金限制暫停,平行前端推廣繼續進行

影響範圍

Polonius 的可穩定化是此次更新中最具長遠影響的里程碑。舊版借用檢查器有若干在語義上安全但被拒絕的模式,Polonius 以更精確的資料流分析消除了這些誤報,預期在生態系穩定後將影響大量依賴複雜借用模式的 Rust 程式碼。

原始來源:Rust Blog


End of article
0
Would love your thoughts, please comment.x
()
x