---
outline: deep
comments: false
showVersion: false
---

# `0.13.0`

2024/6/7，`0.13.0` 发布，历时不足 2 个月，有 73 位贡献者，一共进行了 415 次提交！

本次发布周期相对其他版本较短，主要是对工具链进行升级，如升级至 [LLVM 18](https://ziglang.org/download/0.13.0/release-notes.html#LLVM-18)。

::: warning

有关于各平台和架构的支持情况，本次更新并未进行更改，故在此处不再提及！

:::

## 构建系统

### `Step.Run`：`child` 继承 `stderr` 时获得全局锁

设置 `stdio` 为 `inherit` 的文档：

> 运行步骤被认为具有副作用，因此当它出现在构建图中时总是会执行。
>
> 这也意味着这个步骤将获得全局锁，以防止其他步骤在此期间运行。
>
> 如果子进程崩溃或返回非零退出代码，步骤将失败。

过去缺少该锁的实现，目前已实现，确保 stdout/stderr 只会被一个进程占用。

### 默认情况下将 Windows DLL 安装到 `<prefix>/bin/`

Windows 不支持 `RPATH`，默认情况下仅在少量预定路径中搜索 DLL，其中之一是应用程序加载的目录。

目前，如果您构建一个可执行文件和一个 DLL，链接它们并使用默认配置来安装它们，exe 将进入 `bin/` ，DLL 将进入 `lib/` ，这导致在不手动将 `lib/` 添加到 `PATH` 环境变量中的前提下，exe 无法在运行时找到 DLL。

默认情况下将可执行文件和 DLL 安装到 `bin/` 确保可执行文件能够找到它链接到的 DLL。DLL 导入库仍然安装到 `lib/` 。

> 目前该行为与 [CMake](https://github.com/ziglang/zig/pull/19743) 相同

> [!IMPORTANT] 示例
>
> ```zig
> exe.root_module.linkLibrary(sdl3_lib);
> b.installArtifact(exe);
> b.installArtifact(sdl3_lib);
> ```
>
> 构建结果:
>
> ```sh
> zig-out/
> ├───bin/
> │   ├───example.exe
> │   ├───example.pdb
> │   ├───SDL3.dll
> │   └───SDL3.pdb
> ├───include/
> │   └───SDL3/
> │       ├───SDL.h
> │       └───<omitted>
> └───lib/
>    └───SDL3.lib
> ```

### `Step.ObjCopy`：不接受多个 `section`

现在 `zig objcopy` 不接受保留多个 `section`，如果您将多个 `-j` `.section` 参数传递给 `zig objcopy`，它只会尊重最后传递的一个。

## 编译器

## 将 `YES_COLOR` 环境变量替换为 `CLICOLOR_FORCE`

检测 [`NO_COLOR`](https://no-color.org/) 环境变量并在其设置时禁用颜色输出是大多数 CLI 工具所遵循的标准做法。

当涉及到即使不写入终端时也强制输出颜色的任务时，存在两个标准：`CLICOLOR_FORCE` 和 `FORCE_COLOR`。这两个标准都没有像 `NO_COLOR` 那样普遍存在，但它们都有一定的优先级，并且受到一部分 CLI 工具的尊重。

在 [`e45d24c`](https://github.com/ziglang/zig/commit/e45d24c0de29eb6668e56ea927e15505674833a6) 之前，Zig 使用 ZIG_DEBUG_COLOR 环境变量强制颜色输出，但该提交将其更改为 YES_COLOR 。

`YES_COLOR` 似乎目前在软件中几乎没有先例（[在 GitHub 上搜索 `/(?-i)\bYES_COLOR\b/` 返回了 142 个文件](https://github.com/search?q=%2F%28%3F-i%29%5CbYES_COLOR%5Cb%2F&type=code)）。

与其在混合中加入第三个标准并使用户更难在 CLI 工具中管理彩色输出，不如使用 `CLICOLOR_FORCE` 或 `FORCE_COLOR` 之一进行标记更有意义。

选择 `CLICOLOR_FORCE` 而不是 `FORCE_COLOR` 的原因如下：

- [https://bixense.com/clicolors/](https://bixense.com/clicolors/) 尝试标准化 `CLICOLOR_FORCE`，创建于 2015 年。`FORCE_COLOR` 对应的 [https://force-color.org/](https://force-color.org/) 创建于 2023 年。
- `CLICOLOR_FORCE` 似乎是由 `ls` 于 2000 年在 FreeBSD `4.1.1` 中引入的。`FORCE_COLOR` 似乎是由 chalk JavaScript 库于 2015 年引入的。
- `CLICOLOR_FORCE` 受 CMake 和 Ninja 支持。
- 虽然搜索 `/(?-i)\bCLICOLOR_FORCE\b/` 返回 28.9k 文件并且搜索 `/(?-i)\bFORCE_COLOR\b/` 返回 39k 文件，但前者似乎在用 C/C++ 编写的软件中更常见，而后者似乎更常见于 Node.js 和 Python 相关生态系统。

`CLICOLOR_FORCE` 也会添加到 `zig env` 的输出中。

## `LLVM Backend` 后端

添加了 `loongarch64` 支持。它仍然无法构建 hello world，因为 LLVM 尚未为该目标实现 `fp_to_fp16`。

### `zig-cache` 重命名为 `.zig-cache`

这与更多工具配合得很好。例如，文本编辑器通常会从“在文件中查找”功能中排除该目录。

## Bug 修复

在此发布周期内解决的 43 个错误报告的[完整列表](https://github.com/ziglang/zig/issues?q=is%3Aclosed+is%3Aissue+label%3Abug+milestone%3A0.13.0)。

在这个发布周期中引入并解决了许多错误，为了简洁起见，这些发行说明中省略了大多数错误修复。

## 当前版本包含的 Bugs

Zig 目前存在一些 [已知的 bugs](https://github.com/ziglang/zig/issues?q=is%3Aopen+is%3Aissue+label%3Abug)，甚至包含一些 [编译错误](https://github.com/ziglang/zig/issues?q=is%3Aopen+is%3Aissue+label%3Amiscompilation)！

Zig 目前仍不成熟，即使是使用 `0.13.0` 也可能需要参与 zig 开发才能使之顺利在某些项目开发上正常工作！

当 Zig 达到 `1.0.0` 时，[一级支持](https://ziglang.org/download/0.12.0/release-notes.html#Tier-1-Support) 将获得一个额外的错误策略作为要求。

## 工具链

### LLVM 18

升级 LLVM 至 [`18.1.7`](http://releases.llvm.org/16.0.0/docs/ReleaseNotes.html)，这是本次 `0.13.0` 发版的主要目的！

### musl 1.2.5

Zig 附带了 `musl` 的源代码。当选择 `musl C ABI` 时，Zig 会从源为所选目标构建静态 `musl`。

Zig 还支持定位动态链接的 `musl`，这对于使用它作为系统 `libc` 的 Linux 发行版非常有用，例如 `Alpine Linux`。

从 `v1.2.4` 升级至 `v1.2.5`。

### glibc 2.39

交叉编译时现在可以使用 `glibc` 版本 `2.39`。

## 路线图

`0.14.0` 发布周期的主题将是编译速度。

将在 `0.14.0` 发布周期中努力实现一些即将到来的里程碑：

- 使 `x86` 后端成为调试模式的默认后端。
- `COFF` 的链接器支持。消除对 [`LLD`](https://lld.llvm.org/) 的依赖。
- 启用增量编译以实现快速重建。
- 将并发引入语义分析，进一步提高编译速度。

目前的思路是，优先考虑更快的编译将提高编译器本身的开发速度，从而在接下来的发布周期中修复更多的错误并完成更多的功能。

> 加快编译速度也可能会对语言本身做出一些调整。
