如何在 tests/ui 中用 minicore 编写 #![no_std] 的跨编译测试【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust在 rust 编译器仓库中写 UI 测试时经常需要验证某些代码在#![no_std]下能否为交叉编译目标编译通过而目标上又没有现成的core可用也不希望引入-Zbuild-std。rustc-dev-guide 的 minicore 章节 针对这个场景提供了minicore测试辅助它在 tests/auxiliary/minicore.rs 中提供一组core的 stub 实现让这类测试可以在不依赖目标平台core的情况下编译。本文给出在tests/ui中编写、运行并验证这类测试的完整路径。minicore 适用于哪些测试在动手之前先确认你的测试满足这些条件均来自 minicore 章节与辅助文件头部注释测试需要为交叉编译目标构建但不需要、也不打算运行产物只需要core层面的项目。minicore只针对core项目明确不提供std或alloc项目——如果你的测试要std这条路走不通辅助文件的说明指出它面向的是没有core可用且不想也不需要用-Zbuild-std的交叉编译场景。另外注意// add-minicore指令隐含的两个编译标志-C panicabort—— 由于no_stdno_core的性质不支持 unwinding panic-C force-unwind-tablesyes—— 用于在 assembly 测试中保留 CFI 指令。编写测试文件放置位置UI 测试是tests/ui目录下的一组 Rust 源文件。测试必须按用途放入合适的子目录不允许直接放在tests/ui根下见 UI tests 章节 的 Test organization。新特性可以自建子目录例如tests/ui/rfc1234-widgets/。测试文件用简短描述命名不要包含 issue 编号。最小骨架按 minicore 章节的说明测试需要做四件事加// add-minicore指令、打上#![feature(no_core)]#![no_std]#![no_core]三个属性、导入 minicore并声明编译目标。下面的示例基于 minicore 章节给出的示例整理build-pass行是 UI tests 章节 中记录的通过指令// add-minicore // build-pass // revisions: meow bark //[meow] compile-flags: --targetx86_64-unknown-linux-gnu //[meow] needs-llvm-components: x86 //[bark] compile-flags: --targetwasm32-unknown-unknown //[bark] needs-llvm-components: webassembly #![crate_type lib] #![feature(no_core)] #![no_std] #![no_core] extern crate minicore; use minicore::*; struct Meow; impl Copy for Meow {} // Copy here is provided by minicore各部分的要点// add-minicore是启用 minicore 的指令同时隐含上文提到的两个编译标志#![crate_type]属性用于改变默认的 executable 类型UI 测试默认构建为可执行文件跨编译测试一般不需要运行产物库类型即可导入方式随 edition 不同edition 2015 用extern crate minicoreedition 2018 用use minicore通过revisions 每个 revision 的compile-flags: --target...为不同目标分别编译needs-llvm-components声明该 revision 依赖的 LLVM 后端组件。选择通过/失败预期UI 测试默认预期编译失败check-fail因为多数 UI 测试在测编译器报错。如果你的#![no_std]跨编译测试预期能编译通过必须显式声明UI tests 章节 记录的可选指令有// build-pass—— 编译和链接都应成功但不运行产物。这是 minicore 场景的常用选择因为跨编译测试本来就不运行// check-pass—— 编译成功即可跳过 codegen更便宜// check-fail默认/// build-fail—— 预期编译在类型检查阶段或 codegen 阶段失败。如果想测试某个跨编译目标下必须报错的情况仓库中已有现成参照例如 tests/ui/abi/cannot-return.rs它使用// add-minicore、#![no_core]与extern crate minicore;并对报错行做了//~^ ERROR invalid signature for \extern gpu-kernel function注释。按 UI tests 章节的规则ERROR和WARN默认要求被//~行注释穷尽覆盖这是.stderr快照之外的第二道校验防止.stderr 文件漏生成或误生成。运行与验证UI 测试的验证方式是compiletest 用rustc编译测试把编译器输出与测试旁边的.stderr/.stdout快照比对。运行方式以 UI tests 章节 给出的命令为准./x test tests/ui --pass check其中--pass只影响 UI 测试--pass check会跳过 codegen速度明显更快文档原话在该作者机器上约快两倍适合先快速过滤。需要完整编译codegen、链接时去掉--pass参数即./x test tests/ui或直接指向具体测试文件路径。首次编写或修改测试后用--bless选项生成/更新.stderr、.stdout快照然后人工检查快照内容是否符合预期——这是文档给出的标准验证闭环。几点判断依据快照文件缺失时compiletest 认为对应输出应为空编译器输出会先经过归一化测试目录替换为$DIR、标准库路径替换为$SRC_DIR等跨平台的路径差异通常不需要处理如果输出因目标平台位数不同而不同用normalize-stderr-32bit/normalize-stderr-64bit之类的normalize-*指令写自定义归一化规则让同一个.stderr文件同时适用于 32 位和 64 位平台。另外UI 测试默认带-A unused等一组 lint 预设完整列表见 UI tests 章节的 UI test mode preset lint levels#![no_std]测试里的未使用项通常不会成为噪音若测试本身就要测 unused 警告再加#![warn(unused)]覆盖。缺少所需 core 项目时minicore 章节给出两条维护规则写测试遇到缺项时按此处理如果发现需要的core项目不在 minicore 的 stub 里且它可能被多个测试使用就把它加到测试辅助中minicore必须与core保持同步。为了让使用core和使用minicore时诊断输出一致任何diagnostic属性例如on_unimplemented都应原样复制到minicore中。限制小结minicore只提供core项目不提供std/alloc// add-minicore隐含-C panicabortunwinding panic 不受支持跨编译测试只验证编译build-pass或检查check-pass不运行产物测试文件必须放在tests/ui的某个子目录内不能放根目录。写完后按--bless生成快照 → 人工核对.stderr→ 正常方式跑一遍确认通过的闭环验证测试即可入库。【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考