Stroustrup 在 CppCon 2026 重申 C++ Profiles 框架:靠靜態分析堵住未初始化與容器失效
ISO C++ WG21 (open-std.org) · 2026-09-01
Bjarne Stroustrup 將於 2026 年 9 月 14 日在 CppCon 2026(美國 Aurora, CO)發表主題演講《Profiles for Simplicity and Guarantees》,說明如何在不新增語言分支的前提下,用「Profiles」框架消除未初始化物件讀取、容器與迭代器失效、越界存取三類常見錯誤來源。這套機制的目標是靠編譯期靜態分析達成安全保證,而非仰賴執行期開銷。相關規格其實已經以一系列 WG21 提案的形式送審數年,最新一份初始化子規格 P4222R1 才在 2026 年定案。
核心機制:subset of superset
Profiles 的基礎策略稱為「subset of superset」,出自 Stroustrup 主筆的框架提案 P3274R0(2024-04)。每個 profile 定義一個比完整 C++ 更嚴格的「安全子集合」,但這個子集合仍是合法、可用既有編譯器編譯的標準 C++,只是額外套用靜態分析規則去禁用或標記危險寫法。開發者可以針對特定編譯單元或函式範圍啟用某個 profile,不必整個專案一次到位重寫。因為檢查主要發生在編譯期,符合規則的程式碼理論上不需要額外的執行期成本。
三個具體 profile 的分工
| 提案 | 編號 | 發布日期 | 鎖定的錯誤類型 |
|---|---|---|---|
| Concrete Suggestions | P3038R0 | 2023 | 邊界檢查、基本 invalidation 案例 |
| Profiles Framework | P3274R0 | 2024-04 | 總體機制(annotation + 靜態分析) |
| Invalidation | P3446R0 | 2024-10 | 容器/迭代器/指標失效 |
| Type-and-resource Safety | P3984R0 | 2026-02 | 整合型別與資源安全,前提是先滿足初始化 |
| Initialization Profile | P4222R1 | 2026 | 禁止讀取未初始化記憶體 |
P4222R1 鎖定的問題,是變數、成員變數、以及像 std::vector 內部緩衝區這類「先配置後初始化」模式中,讀到尚未賦值記憶體的情形。P3984R0 進一步把 initialization profile 當作 type-and-resource safety profile 的先決條件——程式碼若無法先滿足初始化保證,就不能宣告符合更完整的型別與資源安全 profile。這種分層設計讓專案可以先採用成本較低的單一 profile,再逐步疊加更嚴格的保證。容器/迭代器失效則由另一份 P3446R0 單獨規範。
影響範圍
這場 keynote 本身不是新提案,而是把過去數年由 Stroustrup 主導、陸續送進 WG21 的一系列 profile 論文重新整合說明。C++ 委員會在記憶體安全議題上長期面臨外部壓力(如美國國安局與白宮 ONCD 先前對記憶體不安全語言的警告),Profiles 是 ISO C++ 提出的官方回應路線之一,與 Sean Baxter 的 Safe C++ 等競爭方案並列討論。由於 Profiles 刻意設計成可增量套用、不必改寫既有程式碼,對大型既有 codebase 的移轉成本評估,會是後續 WG21 全體會議的討論重點。
原始來源:Profiles Framework, P3274R0、Initialization Profile, P4222R1、Invalidation, P3446R0
rustup 1.29.1 發布:更新檢查與多元件安裝雙雙平行化,32-bit Windows 工具鏈安裝規則收緊
GitHub rust-lang/rustup Releases · 2026-09-01
Rust 官方工具鏈管理器 rustup 團隊於 2026-09-01 在 blog.rust-lang.org 公告 1.29.1 版釋出,延續 2026-03-05 1.29.0 引入的並行下載架構。此版本把「檢查更新」與「安裝多個 component」兩個常見操作進一步平行化。同時新增一項會改變既有行為的相容性變更:在 64-bit Windows 上安裝 32-bit 工具鏈,現在必須明確加上 --force-non-host 旗標。完整異動記錄列於專案的 CHANGELOG.md。
效能改動:序列流程改平行處理
rustup update 執行時會先平行檢查各工具鏈是否有可用更新(PR #4752),rustup component add 一次安裝多個 component 時也會平行下載安裝而非逐一處理(PR #4790)。這兩項改動延續了 1.29.0 版由 Google Summer of Code 2025 學生 FranciscoTGouveia 引入的平行下載機制,當時新增的 RUSTUP_CONCURRENT_DOWNLOADS 環境變數(預設值 2)已可控制併發數量。此外 rustup doc 新增 --serve 旗標,可以把本機文件用 HTTP 方式提供瀏覽(PR #4986),不必再手動指定檔案路徑。
相容性與命名變更
安裝 32-bit Windows 工具鏈到 64-bit 主機的行為,從「自動允許」改為「需要顯式旗標」(PR #4935):
# 1.29.1 起,64-bit Windows 上安裝 32-bit 工具鏈需要明確加旗標
rustup toolchain install --force-non-host stable-i686-pc-windows-msvcrustup-init 在某些情況下隱含自動安裝工具鏈的行為被標記為已棄用並印出警告(PR #4840),為未來移除該行為預作準備。文件用語也同步把「target triple」全面改稱「target tuple」(PR #4743、PR #4827、PR #4834)。另外修正了 Windows 上 rustup-init.sh 安裝失敗(PR #4756)與安裝取消後殘留檔案(PR #4996)兩項既有 bug,並正式把 aarch64-pc-windows-gnullvm 列為官方支援的 host 平台(PR #4523)。
CPython 指導委員會凍結 JIT 新功能開發,限六個月內提出正式 PEP
Python Discussions · Steering Council 公告 · 2026-09-01
Python 指導委員會(Steering Council)成員 Pablo Galindo Salgado 於 2026-06-05 在 discuss.python.org 發布公告,凍結 CPython JIT 編譯器的新功能開發。在一份標準軌 PEP 通過審查之前,JIT 相關程式碼只能修 bug 與安全性問題,不得合併任何新功能或效能優化到 main。委員會同時要求六個月內完成正式 PEP,否則將考慮把 JIT 程式碼整個從 main branch 移除。這份公告促成作者群在 2026-07-02 提交 PEP 836《JIT Go Brrr: The Path to a Supported JIT Compiler for CPython》。
背景:流程沒走完就先上車
JIT 編譯器最早在 Python 3.13 隨 PEP 744(僅供資訊性質、非標準軌)進入 main branch,當時並未經過標準軌 PEP 的完整審查與核准流程。指導委員會在公告中坦承這是集體疏失:「collectively we (the Steering Council) have not been as strict about following the process as a change of this complexity and reach deserves」。遺留下來的問題包括長期維護權責、與 free-threading 建置的相容性、對 profiler/debugger 的影響,以及缺乏可量化的成功標準,這些正是指導委員會要求新 PEP 必須回答的項目。
PEP 836 的具體門檻
- 作者:Savannah Ostrowski、Ken Jin、Brandt Bucher;建立於 2026-07-02,對應 Python 3.16 開發週期
- 現況:JIT 目前在有量測的平台上帶來 4%–12% 的 pyperformance 幾何平均效能提升
- Year 1(3.16):JIT 前端由 trace-recording 架構改為 method-based 編譯,並確保與 free-threading 建置相容
- Year 2(3.17):效能優化與相容性驗證,門檻是 JIT + free-threaded build 需在 pyperformance 上達到至少 20% 幾何平均提升
- 指導委員會預計最快在 Python 3.17 第一個 beta(
3.17.0b1)前決定是否讓 JIT 轉為正式支援功能
影響範圍
這次凍結不影響既有 JIT 功能——3.13 起隨附的 JIT 仍會持續收到 bug 修正與資安更新,只是所有新特性與效能迭代都要等 PEP 836 定案。對想在 production 依賴 JIT 效能的使用者而言,現階段的訊息是能力尚未定型:LLVM 依賴造成的 Linux 套件散布問題、與 free-threading(PEP 703)的長期整合,都要等到 3.17 開發週期才有明確答案。委員會也把六個月訂為「有彈性的目標」而非硬性期限,若 PEP 討論卡關,委員會表示可以延長,不會期限一到就強制移除程式碼。