Zig 0.17.0 開發更新：@bitCast 語義、LLVM 後端與建置系統

Zig 0.17.0 開發更新：@bitCast 語義、LLVM 後端與建置系統

Zig 正在演進其核心編譯器與建置基礎設施，以提升效能、可預測性與開發者體驗。關鍵更新包括將 @bitCast 重新定義為與端序無關（endian-agnostic），更有效地在 LLVM 後端中降低任意寬度的整數（arbitrary-width integers），以及對 zig build 流程進行重大的架構重構。

全新的端序無關 @bitCast 語義

Zig 重新定義了 @bitCast，使其運作於類型的邏輯位元表示法，而非重新解釋記憶體中的原始位元組。這項改變確保了位元轉換（bitcasting）在不同的目標架構上行為一致，消除了先前對目標端序的依賴。

邏輯位元佈局

在新語義下，每個支援 @bitCast 的類型都具有一個「邏輯位元佈局」——一個有序的位元序列。例如：

  • 整數：一個 u5 由 5 個邏輯位元組成，由最低有效位元（least-significant）到最高有效位元（most-significant）排序。
  • 陣列：一個 [2]u5 由 10 個邏輯位元組成（第一個元素的 5 個位元，接著是第二個元素的 5 個位元）。

對聚合類型的影響

最顯著的變化發生在對陣列或向量等聚合類型進行位元轉換時。先前，將 [2]u8 位元轉換為 u16 會在不同端序（big-endian 與 little-endian）的目標上產生不同的值。現在，此操作是端序無關的：第一個陣列元素總是成為結果整數的 8 個最低有效位元。

其他 @bitCast 變更

  • 列舉 (Enums)：現在允許對列舉進行 @bitCast。
  • 指標 (Pointers)：現在禁止將指標轉換為向量，或從向量轉換為指標。

LLVM 後端改進與效能

Zig 更新了 LLVM 後端處理任意位元寬度整數類型（例如 u4、i13）的方式，以避免與 LLVM 原生記憶體中的位元整數類型相關的次佳優化與錯誤編譯問題。

整數降低 (Integer Lowering)

先前，Zig 會將這些類型直接降低（lowered）至 LLVM IR 的位元整數類型。新的實作方式僅在 SSA 形式的值中使用位元整數類型，並在將其存儲於記憶體時將其擴展為 ABI 大小的類型（i8、i16、i32 等）。這項方法與 Clang 降低 C 語言的 _BitInt(N) 的方式一致，確保在 LLVM 內提供更好的支援與更可靠的優化。

效能增益

這項改變已在恢復遺失的優化方面展現了成功。Zig 編譯器本身看到了大約 5% 的效能提升，這暗示著在即將推出的 0.17.0 版本中，使用者將獲得類似的執行期效能增益。

建置系統架構重構

為了提高 zig build 的速度，建置系統現在將「配置器 (configurer)」流程與「製造器 (maker)」流程分離。

配置器與製造器的分離

  • 配置器 (The Configurer)：build.zig 檔案會在除錯模式下被編譯成一個小型流程。它在記憶體中建構建置圖（build graph）與其序列化為二進位配置檔案。
  • 製造器 (The Maker)：父層級的 zig build 流程會非同步地以發佈模式編譯一個「製造器」流程。接著，這個製造器流程會執行序列化後的建置圖。

新架構的優益

  1. 減少編譯量：變更時僅需編譯使用者的 build.zig 邏輯，而非整個建置系統。
  2. 快取配置：如果配置未變更（例如，當加入 -freference-trace 等 CLI 旗標時），建置系統可以完全跳過重新執行 build.zig 邏輯。
  3. 優化的執行：執行建置圖的流程現在是以啟用優化的模式編譯的。

基準測試顯示，簡單指令的實際執行時間（wall-clock time）大幅減少；例如，zig build -h 從 150ms 降低到了 14.3ms。

其他值得注意的編譯器與工具更新

ELF Linker 與增量編譯

  • 新的 ELF Linker：新的 ELF linker（透過 -fnew-linker 啟用）現在可以使用 LLVM 與 LLD 函式庫來建置自託管的 Zig 編譯器。它支援在 x86_64 Linux 上進行快速的增量重新建置，將某些重新建置時間縮短至低至 30ms。
  • LLVM 增量支援：增量編譯現在可與 LLVM 後端配合使用，讓開發者可以在毫秒級別而非秒級別接收到編譯錯誤訊息。

類型解析重設計

  • 編譯器的內部類型解析現在變得更「懶惰 (lazier)」。如果一個類型僅作為命名空間使用且從未被初始化，編譯器將不再分析其欄位，從而防止在未使用的欄位中觸發不必要的 @compileError。
  • 依賴迴圈錯誤訊息已重新設計，能提供關於迴圈起源點的詳細說明。

Windows 原生 API 偏好

  • Zig 標準函式庫正趨向於偏好使用原生 API (ntdll.dll) 而非 Win32 封裝 (kernel32.dll)，以避免不必要的堆積分配 (heap allocations)、膨脹與非決定性的失敗模式。這在新的熵值 (entropy) 實作中（避免使用 bcryptprimitives.dll）以及檔案 I/O (NtReadFile/NtWriteFile) 中尤為明顯。

套件管理

  • 本地儲存：擷取的套件套件現在儲存在專案本地的 zig-pkg 目錄中，這有助於離線建置與更簡單的 IDE 整合。
  • 專案覆蓋 (Project Overrides)：--fork=[path] 旗標允許開發者暫時以本地原始碼檢出（checkout）來覆蓋依賴項，以便在快速迭代時無需修改 build.zig.zon。

社群觀點

雖然大多數技術社群成員認為這些深入研究是很有價值的，但對於新的 @bitCast 語義仍存在一些爭議。一位使用者指出：

"這是一個巨大的錯誤。你絕對不會預期像 bitCast 這樣的操作會變成這樣... 為什麼要將如此簡單且底層的內容變得複雜且高層次化？"

相反地，其他使用者則強調了這些變更對於處理位元封裝的二進位標頭檔（bit-packed binary headers）而無需手動進行位元操作的實用性。

Sources