Linux 7.3-rc1 合併窗收官創次高提交量、Rust 以 #[splat] 屬性徵求函式多載實驗
LWN.net · 2026-08-30；Inside Rust blog · 2026-08-19
Linus Torvalds 於 2026 年 8 月 30 日發布 Linux 7.3-rc1，正式關閉本輪合併窗，共有 15,267 個提交拉入主線，是歷史上合併窗提交量第二高的紀錄，僅次於 6.7。同一週，Rust 專案在 Inside Rust 部落格發出函式多載（function overloading）徵求實驗公告，透過 nightly 限定的 #[splat] 屬性，讓呼叫 C++ 多載函式時能寫出接近原生的引數語法。兩者分屬作業系統核心與程式語言前沿設計，卻都是本週各自專案最重要的動態。
核心改動
本輪合併窗中，AMD DCN6 顯示控制器的暫存器標頭檔就占了整體 diff 約三分之一，Torvalds 在公告信中表示「如果把這一大塊遮起來，其餘部分看起來相當正常」。除此之外，rc1 還拉入以下較受矚目的變動：
- AMD Zen 6 平台的初步致能
- Btrfs 檔案系統的效能改善
- 2026 年版 Valve Steam Controller 驅動支援
- Intel 混合架構（P-core/E-core）CPU 排程最佳化
- Nouveau NVK 驅動加入 Vulkan Video 支援
- Apple M3 Ultra/Pro/Max 晶片初步支援
- FailFS 檔案系統併入主線
影響範圍
依照慣例，7.3 正式版預計還要再經過約七到八輪 rc 才會釋出，這段期間是子系統維護者與發行版打包者回歸測試的主要窗口。由於 GPU 標頭檔案灌水，實際程式邏輯變動比 diff 行數顯示的更為集中，圖形堆疊測試者仍應留意 DCN6 相關迴歸。受益族群包含使用 Steam Controller 的玩家、Btrfs 重度使用者，以及在 Apple Silicon 上執行 Linux 的社群。
另一方面，Rust 專案與 Rust 基金會的 Rust-C++ Interop Initiative 合作，針對讓 Rust 呼叫 C++ 多載函式更符合人體工學的問題提出實驗方案。Rust 語言本身不支援傳統意義的函式多載，過去只能靠 bindgen 之類工具把每個多載版本改名成 hypot、hypot1、hypot2，新機制則嘗試在編譯器層面解決這個落差。
核心改動
此次徵求實驗的核心是 #[splat] 屬性：函式參數宣告為一個 tuple 型別並標上 #[splat]，呼叫端就能把個別引數「攤平」傳入，而不必手動包成 tuple。相關能力已在 2026-07-31 之後的 nightly 建置中可用，並由 tracking issue #153629 追蹤進度，目前狀態為實作未完成（S-tracking-impl-incomplete）。
// nightly-only，仍屬實驗性語法
fn hypot(#[splat] args: (f64, f64, f64)) -> f64 { /* ... */ }
// 呼叫端看起來就像一般的多載函式
let d = hypot(3.0, 4.0, 12.0);官方公告列出四項設計準則：維持 Rust 慣用風格、讓呼叫多載 FFI 函式與原生呼叫一樣簡單、不犧牲原始 C/C++ 介面的可維護性，以及在多個候選中挑出多數開發者預期的那個多載版本。這套機制建立在既有的 trait 解析與 tuple 型別系統之上，並未新增專門的多載語法糖。
影響範圍
目前這項提案尚未形成正式 RFC，只是一個可能隨時變動或撤回的 nightly 實驗特性，Rust 專案希望編譯器與 interop 工具開發者實際試用後，透過 Zulip 的 #t-lang/interop 頻道回報問題與使用情境。追蹤議題中仍列出多個未解問題，包括 trait coherence 限制是否會讓部分外部多載無法呼叫、閉包是否支援 splat、哪些 ABI 能承載此語法，以及多載符號在連結層如何消歧義。官方另外提供 overloading-examples 範例庫，供 bindgen、cxx 等 FFI 工具作者參考典型使用情境。
原始來源：LWN.net - Kernel prepatch 7.3-rc1、Inside Rust blog - Function Overloading Call for Experimentation、rust-lang/rust#153629