收尾：Cargo features、测试、lint 与 CI

先问一句：现在有没有办法不要 repl？#

第一反应：Cargo 有 --no-default-features，试试。

1
$ cargo build -p pebble-cli --no-default-features
2
   Compiling pebble-cli v0.1.0 (/tmp/pebble-rebuild-15/crates/pebble-cli)
3
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 9.33s

编译通过，听上去成功了。看看依赖：

1
$ cargo tree -p pebble-cli --no-default-features -e normal | grep rustyline
2
└── rustyline v18.0.1
3
$ ./target/debug/pebble repl </dev/null
4
Pebble REPL. Type :help for commands, :quit to exit.
5
pebble>

rustyline 还在，repl 也还在。原因很朴素：--no-default-features 的意思是”不要开启 default 这个 feature 里列的东西”，而我们的 Cargo.toml 里根本没有写任何 [features]，所以没有什么可关的。Cargo 不会因此报错，这个开关在这里是空操作。

第一步：把依赖标成 optional#

在 crates/pebble-cli/Cargo.toml 里，把 rustyline.workspace = true 改成：

1
rustyline = { workspace = true, optional = true }

optional = true 的意思是”这个依赖默认不编译，除非某个 feature 点名要它”。现在不加任何 feature，直接构建：

1
$ cargo build -p pebble-cli
2
   Compiling pebble-cli v0.1.0 (/tmp/pebble-rebuild-15/crates/pebble-cli)
3
error[E0433]: cannot find module or crate `rustyline` in this scope
4
  --> crates/pebble-cli/src/repl.rs:15:5
5
   |
6
15 | use rustyline::error::ReadlineError;
7
   |     ^^^^^^^^^ use of unresolved module or unlinked crate `rustyline`
8
   |
9
   = help: if you wanted to use a crate named `rustyline`, use `cargo add rustyline` to add it to your `Cargo.toml`
10

11
error[E0432]: unresolved import `rustyline`
12
...
13
error: could not compile `pebble-cli` (bin "pebble") due to 2 previous errors

这个错误是对的：我们声明了一个”默认不编译”的依赖，却没有说什么时候该编译它，repl.rs 里的 use rustyline::... 就悬空了。

第二步：写 [features]#

在同一个文件的 [dev-dependencies] 前面加：

1
[features]
2
default = ["repl"]
3
# The interactive `pebble repl` subcommand (pulls in the line editor).
4
repl = ["dep:rustyline"]

读法：repl 是一个 feature 的名字，它开启时会启用 rustyline 这个可选依赖（dep: 前缀的意思是”我指的是依赖本身，不是另一个同名 feature”）；default 是一个特殊的 feature 名，列在里面的东西在没人指定时自动开启。所以普通的 cargo build 仍然带 repl，行为不变：

1
$ cargo build -p pebble-cli
2
   Compiling pebble-cli v0.1.0 (/tmp/pebble-rebuild-15/crates/pebble-cli)
3
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.45s

而 --no-default-features 这次真的有东西可以关了，于是 rustyline 不再被编译，repl.rs 又找不到它：

1
$ cargo build -p pebble-cli --no-default-features
2
   Compiling pebble-cli v0.1.0 (/tmp/pebble-rebuild-15/crates/pebble-cli)
3
error[E0433]: cannot find module or crate `rustyline` in this scope
4
  --> crates/pebble-cli/src/repl.rs:15:5
5
...

同一个错误。现在轮到源代码：不开 repl 的时候，repl.rs 整个文件都不应该参与编译。

第三步：#[cfg(feature = "repl")]#

Cargo 把开启的 feature 作为 --cfg 'feature="repl"' 传给 rustc。源码里用 #[cfg(...)] 属性按它来取舍：条件不成立，被标注的那个条目就好像从来没有写过。这有点像 #ifdef，区别有两个：它作用在语法树的条目上（一个模块、一个函数、一个枚举变体、一条 match 分支），不是按行的文本替换；而且条目被取舍之前，rustc 仍然把它解析成合法的语法，所以你没法用 #[cfg] 藏一段根本不是 Rust 的东西。

先只给 main.rs 里的 mod repl; 加上：

1
#[cfg(feature = "repl")]
2
mod repl;

1
$ cargo build -p pebble-cli --no-default-features
2
   Compiling pebble-cli v0.1.0 (/tmp/pebble-rebuild-15/crates/pebble-cli)
3
error[E0433]: cannot find module or crate `repl` in this scope
4
  --> crates/pebble-cli/src/main.rs:30:26
5
   |
6
30 |         Command::Repl => repl::run(),
7
   |                          ^^^^ use of unresolved module or unlinked crate `repl`
8
   |
9
note: found an item that was configured out
10
  --> crates/pebble-cli/src/main.rs:17:5
11
   |
12
16 | #[cfg(feature = "repl")]
13
   |       ---------------- the item is gated behind the `repl` feature
14
17 | mod repl;
15
   |     ^^^^
16
...

编译器很客气：它不仅指出 repl 找不到，还告诉你”有一个被 configured out 的条目叫这个名字，被 repl feature 守着”。这是 cfg 比 #ifdef 友好的地方：C 里你只会得到 undeclared identifier，然后自己去找是哪个宏把它藏起来了。

下一处是 main 里的 match 分支。给它加上同样的属性：

1
        #[cfg(feature = "repl")]
2
        Command::Repl => repl::run(),

1
$ cargo build -p pebble-cli --no-default-features
2
error[E0004]: non-exhaustive patterns: `cli::Command::Repl` not covered
3
  --> crates/pebble-cli/src/main.rs:28:24
4
   |
5
28 |     let result = match cli.command {
6
   |                        ^^^^^^^^^^^ pattern `cli::Command::Repl` not covered
7
...

match 是穷尽性检查的（第 3 篇），分支没了，变体还在，于是编译器拒绝。最后一处是 cli.rs 里的枚举变体本身，把属性放在 Repl, 上面（文档注释前后都行，tag 里它在文档注释后面）：

1
    /// Start an interactive read-eval-print loop.
2
    #[cfg(feature = "repl")]
3
    Repl,

1
$ cargo build -p pebble-cli --no-default-features
2
   Compiling pebble-cli v0.1.0 (/tmp/pebble-rebuild-15/crates/pebble-cli)
3
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.09s

三个 #[cfg(feature = "repl")]，一个在 mod repl; 上，一个在 match 分支上，一个在枚举变体上，加上 Cargo.toml 的两处改动，就是整个”可选 repl”。这三处不是我随便选的：你可以把它们理解成”一个功能在程序里有三个落脚点：代码、入口、命令行的声明”，每一个都被编译器逼着你处理，漏掉哪个，哪个就报错。我在 /tmp/pebble-rebuild-15 里验证过，现在 crates/pebble-cli 下的 Cargo.toml、cli.rs、main.rs 与 tag 逐字节相同。

看看效果#

没有 repl 的二进制，子命令列表里就没有它：

1
$ ./target/debug/pebble --help
2
Pebble: a small scripting language and toolchain
3

4
Usage: pebble <COMMAND>
5

6
Commands:
7
  run     Execute a source file on the tree-walker or the bytecode VM
8
  tokens  Print the token stream of a source file
9
  parse   Print the parsed abstract syntax tree of a source file
10
  check   Lex, parse, and compile source files without running them
11
  bench   Time both backends on a source file
12
  help    Print this message or the help of the given subcommand(s)

这是 clap 的派生宏读到的东西：派生宏拿到的枚举定义里，被 cfg 去掉的变体已经不在了，所以不需要任何额外代码。直接运行它：

1
$ cargo run -q -p pebble-cli --no-default-features -- repl
2
error: unrecognized subcommand 'repl'
3

4
  tip: a similar subcommand exists: 'help'
5

6
Usage: pebble <COMMAND>
7

8
For more information, try '--help'.
9
$ echo $?
10
2

退出码 2 是 clap 的”用法错误”，和第 7 篇的 unknown_subcommands_are_usage_errors 同一类。两个版本的体积和依赖，用发布 profile 各编一次：

1
$ cargo build -q -p pebble-cli --release && ls -l target/release/pebble
2
1915528 ... target/release/pebble
3
$ cargo build -q -p pebble-cli --release --no-default-features && ls -l target/release/pebble
4
1452928 ... target/release/pebble

$(1915528 - 1452928) / 1915528 \approx 24\%$。依赖方面，cargo tree -p pebble-cli -e normal --prefix none | sort -u | wc -l 是 56，加上 --no-default-features 是 43，少了 13 个包：cfg-if、endian-type、home、libc、log、memchr、nibble_vec、nix、radix_trie、rustyline、smallvec、unicode-segmentation、unicode-width（两份清单 sort -u 之后 diff 的结果）。

测试也跟着变了：

1
$ cargo test -p pebble-cli --no-default-features
2
     Running unittests src/main.rs (target/debug/deps/pebble-88f4cb96ddecbc63)
3
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
4
     Running tests/cli.rs (target/debug/deps/cli-c82fb2694cfbd503)
5
test result: ok. 12 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.09s

默认配置下是”3 个单元测试加 12 个集成测试”（第 14 篇的数字），没有 repl 时单元测试变成 0 个：那 3 个测试是 repl.rs 里 MetaCommand 的测试，文件整个不存在了，它们也就不存在了。12 个集成测试一个不少，因为它们只通过二进制的公开行为说话。

为什么 CI 要单独跑一遍 --no-default-features#

这就是 CI 里那两行的作用。cargo test --workspace --all-features 只测”全开”这一种组合；“全关”这一种组合是另一个程序，它能因为一个忘了写的 #[cfg] 编不过去，而全开的组合永远发现不了。上面我们按顺序踩过的三个错误，每一个都是”全开通过、全关失败”的典型。所以 CI 的 clippy 任务多一行 cargo clippy -p pebble-cli --no-default-features --all-targets -- -D warnings（连死代码警告也算失败），build 任务多一行 cargo build -p pebble-cli --no-default-features。

关于这两行里的 -p pebble-cli，我顺手试了 --workspace --no-default-features：cargo tree --workspace --no-default-features -e normal | grep -c rustyline 输出 0，cargo clippy --workspace --no-default-features --all-targets -- -D warnings 也通过。在 resolver 3 下，--no-default-features 对选中的每个包都生效，所以 -p pebble-cli 只是更窄的写法，不是必要的写法。

cfg 还能干什么#

cfg 的条件不只有 feature。target_os、target_pointer_width、debug_assertions、test 都是。#[cfg(test)] mod tests 是第 1 篇就写过的。在 ~/rust-lab 里的 src/bin/ch15_cfg.rs（完整版在 lab/rust-lab/src/bin/ch15_cfg.rs）：

1
#[cfg(target_os = "linux")]
2
fn platform() -> &'static str {
3
    "linux"
4
}
5

6
#[cfg(target_os = "windows")]
7
fn platform() -> &'static str {
8
    "windows"
9
}
10

11
#[cfg(not(any(target_os = "linux", target_os = "windows")))]
12
fn platform() -> &'static str {
13
    "something else"
14
}
15

16
fn main() {
17
    println!("compiled for {}", platform());
18
    println!("cfg! is an ordinary bool: {}", cfg!(target_os = "linux"));
19
    println!("debug assertions: {}", cfg!(debug_assertions));
20
    println!("pointer width: {}", if cfg!(target_pointer_width = "64") { 64 } else { 32 });
21
}

1
$ cargo run --quiet --bin ch15_cfg
2
compiled for linux
3
cfg! is an ordinary bool: true
4
debug assertions: true
5
pointer width: 64

同一个名字有三个定义，每次编译只留一个。#[cfg(...)] 是”这个条目存不存在”；cfg!(...) 是一个宏，展开成 true 或 false，两个分支的代码都要通过类型检查，所以它不能用来藏平台相关的 API。ch15_cfg_missing.rs 调用一个只在 Windows 上存在的函数：

1
$ cargo build --bin ch15_cfg_missing
2
error[E0425]: cannot find function `only_on_windows` in this scope
3
 --> src/bin/ch15_cfg_missing.rs:7:20
4
  |
5
7 |     println!("{}", only_on_windows());
6
  |                    ^^^^^^^^^^^^^^^ not found in this scope
7
  |
8
note: found an item that was configured out
9
 --> src/bin/ch15_cfg_missing.rs:2:4
10
  |
11
1 | #[cfg(target_os = "windows")]
12
  |       --------------------- the item is gated behind the `windows` feature
13
2 | fn only_on_windows() -> &'static str {
14
  |    ^^^^^^^^^^^^^^^

(注意倒数第三行说 “windows feature”，其实是 target_os，这是 rustc 1.95.0 这一条提示的措辞不精确，不影响你读懂它。) Pebble 自己没有平台相关的代码，pebble-sys 里的 C 用 cc 编，在 Linux 和 macOS 上都通过（CI 的 test 任务在这两个系统上各跑一遍，下面会读到）。所以这一节是一个”T”：实验里编过，仓库里没用。

全部加起来#

在 /tmp/pebble-rebuild-15 里，cargo test --workspace --all-features 的真实结果（单元测试加集成测试，文档测试单列）：

加起来 163 个；文档测试 5 个通过、3 个 ignore。我没有手算，是把 33 行 test result 的 passed 列用 awk 加了一遍：

1
$ cargo test --workspace --all-features 2>&1 | grep "test result" | awk '{p+=$4; i+=$8} END{print p, i}'
2
168 3

168 个通过，3 个被忽略，0 个失败。几个值得一提的细节：

• 带 #[should_panic] 的测试有四个（pebble-span、pebble-gc 两个、pebble-sys）。它们证明的是”这个调用必须 panic，而且消息里含有这个字符串”。
• 带 #[tokio::test] 的是 pebble-net 里的四个（第 14 篇）。
• pebble-bench 的 Criterion 基准（第 12 篇）不在这次 cargo test 里：cargo test 的 Running 列表里没有 backends，要用 cargo bench -p pebble-bench 另外跑。
• 差分测试（五个）在 Running tests/differential.rs 下，名字都是 *_backends_agree：

1
$ cargo test -p pebble-bench --test differential
2
test closures_keep_private_state_backends_agree ... ok
3
test lists_are_shared_by_reference_backends_agree ... ok
4
test strings_and_negative_indexing_backends_agree ... ok
5
test loops_with_break_and_continue_backends_agree ... ok
6
test recursion_and_arithmetic_backends_agree ... ok
7
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s

第六个差分程序是被删掉的那个，原因在第 12 篇里。

最后一个需要说清的：这些数字都只是”代码被执行过且断言没有失败”。168 个测试不是正确性的证明，是一道下限。第 10 篇里我故意弄坏编译器，看测试漏掉了什么，这个习惯值得留下来。

工作区里的 lint 配置#

根 Cargo.toml 里的三段：

1
[workspace.lints.rust]
2
rust_2018_idioms = "warn"
3
unsafe_op_in_unsafe_fn = "warn"
4

5
[workspace.lints.clippy]
6
all = "warn"

每个 crate 的 Cargo.toml 底部有 [lints] workspace = true（第 1 篇里的写法），继承它们。rust_2018_idioms 是一组”别用旧习惯”的 lint；unsafe_op_in_unsafe_fn 要求 unsafe fn 里面的不安全操作也要用 unsafe {} 框起来（第 11、13 篇）；clippy::all 是 clippy 的默认一大组。它们只是警告，是 CI 里的 -D warnings 把警告变成错误：

1
$ cargo clippy --workspace --all-targets --all-features -- -D warnings
2
    Checking pebble-net v0.1.0 (/tmp/pebble-rebuild-15/crates/pebble-net)
3
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 8.00s

警告在本地开发时不阻碍你运行代码，CI 里不允许任何一条留下来，这是一种分工：本地可以带着警告试验，合并不行。

什么时候可以说”我知道，闭嘴”#

#[allow(...)] 是对一条 lint 的豁免，它能放在不同的粒度上，Pebble 用了两个：

• 整个 crate：pebble-value 和 pebble-interp 的开头都有 #![allow(clippy::mutable_key_type)]。pebble-value 里附了五行注释解释为什么键的哈希是稳定的，pebble-interp 里两行注释指回它（第 8 篇里 clippy 抗议的故事：对着一个 RefCell 里有计数器的键类型，规则本身是对的，只是这里的哈希按指针地址算）。
• 一个测试函数：pebble-sys 里的 fold_empty_range_returns_init 上有 #[allow(clippy::reversed_empty_ranges)]，因为 5..=4 在那里是故意写的空区间。

顺带一提：我在第 8 篇试过，把 crate 级的 allow 删掉后，库代码没有意见，只有 --all-targets 时测试里的 HashMap::new() 触发它，所以更窄的写法是把它只放在测试函数上；tag 选择的是 crate 级一次关掉，我觉得两种都说得过去。

规矩只有一条：每一个 allow 旁边必须有一句话说明为什么。 没有注释的 allow 是在把噪音藏进地毯下面。

把”不安全”限制在能看见的地方#

#![forbid(unsafe_code)] 比 deny 更强：不能被内层的 #[allow] 覆盖。grep -rn "forbid(unsafe_code)" crates 在 tag 里作为属性命中 pebble-span、diag、lexer、ast、parser、value、interp、bytecode、vm、bench、net 和 cli（pebble-nostd 的 lib.rs 里那一处命中是注释，说它不能用这条属性）；没有这个属性的是 pebble-gc（有 bump.rs 里的 unsafe，第 11 篇）、pebble-sys 和 pebble-nostd（第 13 篇），还有 pebble-macros（它里面没有 unsafe 这个词，只是没写这一行）。也就是说，在 16 个 crate 里，需要人来为内存安全签字的代码只可能出现在三个 crate 里，而且 grep unsafe 就能把它们全部找出来。我觉得这是 Rust 里最被低估的一条工程性质：安全性的”审计范围”是机器可计算的。

#[must_use]#

1
$ grep -rn "must_use" crates --include=*.rs | wc -l
2
111

111 行。#[must_use] 放在一个函数或类型上，调用者丢掉返回值会得到警告。Span::merge 返回新的 Span，如果你写了 a.merge(b); 然后什么都不用，这几乎一定是个 bug（它不修改 a），编译器会告诉你。Result 本身就是 #[must_use] 的，这是为什么忘了处理错误会被警告。

配置文件一览#

这些全是仓库根目录下的小文件。我把它们按读到的内容列出来：

1
[toolchain]
2
channel = "stable"
3
components = ["rustfmt", "clippy"]
4
profile = "minimal"

rustup 进入这个目录时会自动选 stable 通道并保证装了 rustfmt 和 clippy；profile = "minimal" 不装文档和其他组件。注意它没有钉死一个具体版本：版本由别的东西钉。

1
edition = "2024"
2
max_width = 100
3
use_field_init_shorthand = true
4
use_try_shorthand = true

1
msrv = "1.88"

msrv 告诉 clippy “这个项目声称最低支持 1.88”，它就不会推荐只在更新的版本才有的写法。根 Cargo.toml 里的 rust-version = "1.88" 是同一个声明，Cargo 用它拒绝在更旧的编译器上构建；第 10 篇的 let 链就是 1.88 才稳定的。（诚实说明：我没有装 1.88 去验证这个声明，我手里只有 1.95.0。）

flake.nix 是 Nix 用户的开发环境，也就是我在第 1 篇里让你 nix develop 的那个。tag 里的内容是：

1
inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";
2
...
3
packages = with pkgs; [ rustc cargo rust-analyzer clippy rustfmt gdb hyperfine pkg-config zlib ];

flake.lock 把 nixpkgs 钉在一个具体的提交上，所以所有人的 rustc 是同一个。这就是上面说的”版本由别的东西钉”：rust-toolchain.toml 管通道，Nix 的锁文件管版本。.envrc 里只有一行 use flake，配合 direnv 进入目录自动进环境，目录里还有 .editorconfig（缩进、行尾，所有编辑器通用）。

Cargo.lock 提交在仓库里，里面 143 个包的精确版本和校验和（grep -c '^name = ' Cargo.lock 是 143，包括我们自己的 16 个 crate）。老的建议是”库不提交锁文件，因为使用者会自己解析；应用提交”；新版 Cargo 文档的说法是没那么绝对（我没有逐条核对，细节以 Cargo Book 为准）。Pebble 有一个二进制，所以无论哪种说法都该提交：让每次构建拿到一样的依赖。dependabot.yml 每周自己提一个 PR 来更新它。

发布 profile#

1
[profile.release]
2
lto = "thin"
3
codegen-units = 1
4

5
[profile.bench]
6
inherits = "release"

lto = "thin" 是链接期优化，允许跨 crate 内联（Pebble 有 16 个 crate，解释器的热点在 pebble-value 和 pebble-vm 之间）；codegen-units = 1 让编译器把整个 crate 当成一个编译单元，牺牲编译速度换一点运行速度；bench profile 继承 release，保证 Criterion 测的是发布构建。我没有单独测过这两个设置各自的收益，所以不给数字。

两个小债#

#[inline]。 Pebble 里没有写 #[inline]，我也没有测过它对 Pebble 有没有帮助。它是一个”建议”：对一个小函数，提示编译器可以内联。在同一个 crate 里，编译器自己会决定；跨 crate 时，一个非泛型函数默认只有机器码，没有可内联的函数体，#[inline] 让函数体也被导出，使别的 crate 可以内联它（泛型函数天生就导出函数体，因为要单态化，第 5 篇）。src/bin/ch15_inline.rs 里有三种写法，它们能编译、能运行，我只能保证这么多：

1
$ cargo run --quiet --bin ch15_inline
2
38 2654435768 608876246

#[inline(always)] 和 #[inline(never)] 是更强的版本。这一类属性我的原则是：不测量就不加。

解引用强制转换。 第 5 篇讲过它在 Box 和 Vec 上的样子（&Box<Expr> 变 &Expr，&Vec<T> 变 &[T]），第 2、7 篇里 &String 变 &str、Source::load(&args.file) 把一个 &PathBuf 传给要 &Path 的参数，也都用了它，我当时只讲了”PathBuf 对应 &Path，像 String 对应 &str”。这里把它补完整，答案是 deref coercion：当 T: Deref<Target = U>，编译器会在需要 &U 的地方自动把 &T 转成 &U，而且可以连续转几步。src/bin/ch15_deref.rs：

1
fn load(path: &Path) -> usize { path.as_os_str().len() }
2
fn shout(text: &str) -> String { text.to_uppercase() }
3
fn total(numbers: &[i64]) -> i64 { numbers.iter().sum() }
4

5
fn main() {
6
    let owned = PathBuf::from("examples/fib.pebble");
7
    println!("{}", load(&owned));      // &PathBuf where &Path is expected
8
    let name = String::from("pebble");
9
    println!("{}", shout(&name));      // &String where &str is expected
10
    let list = vec![1, 2, 3];
11
    println!("{}", total(&list));      // &Vec<i64> where &[i64] is expected
12
    let boxed = Box::new(String::from("boxed"));
13
    println!("{}", shout(&boxed));     // &Box<String> -> &String -> &str: two steps
14
}

1
$ cargo run --quiet --bin ch15_deref
2
19
3
PEBBLE
4
6
5
BOXED

(清单里省略了 use std::path::{Path, PathBuf}; 这一行。) 这就是为什么 Pebble 的函数参数写 &str、&[T]、&Path 而不是 &String、&Vec<T>、&PathBuf：借用版本更通用，调用者拥有的任何一种形态都能传进来。第 5 篇的 visitor.visit_expr(operand)，operand 是 &Box<Expr> 而参数要 &Expr，也是同一个机制。它与 C++ 的隐式转换不同：它只做 Deref 这一种，不会把一个 i32 悄悄变成 i64。

实验清单#

这一篇用到的所有实验文件都在仓库的 lab/ 目录里（lab/rust-lab 是主实验室）。按第 1 篇的方式把 tag 克隆到 ~/pebble-tag 后，它们就在 ~/pebble-tag/lab/rust-lab，在那里运行（cd ~/pebble-tag/lab/rust-lab，也可以把这个目录复制成 ~/rust-lab）。表里 lab- 开头的文件属于旁边的独立实验 crate，命令里写了完整的目录。

补丁（lab/exercises/*.patch）要在一份干净的 ~/pebble-tag 里从仓库根目录应用，跑完用 git apply -R lab/exercises/ch15-features.patch 之类的命令还原。

文章里把 lab-ch15-tests 弄坏的两个版本没有放进仓库：把 src/lib.rs 文档测试里的 2 改成 3 就是失败的文档测试；tests/private.rs（一行 use lab_ch15_tests::secret;）会让朴素的 cargo test 直接编译失败，所以我没有把它放进 lab/，要复现就自己建这个文件，再跑 cargo test --test private，得到文章里的 E0603。