数据库流处理后端数据工程【免费下载链接】risingwaveEvent streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale.项目地址https://gitcode.com/gh_mirrors/ri/risingwave点击查看免费下载导读本文围绕 RisingWave 仓库中 lints/README.md 所描述的lintscrate 展开系统讲解 RisingWave 如何借助cargo dylint构建属于自己的 Clippy 扩展用于在编译期强制执行团队代码风格与最佳实践。读完本文你将掌握cargo-dylint的安装与运行方式、RisingWave 现有 lint如rw::format_error的实现原理与分组机制、如何新增一条 lint、如何编写 UI 测试以及升级 rustc toolchain 时的注意事项可以直接在自己的 Rust 工程中复刻这套自定义 lint 体系。lintscrate 是 RisingWave 专门用于承载自定义 lint 的独立 crate位于仓库根目录下的 lints 目录其中src存放 lint 实现、ui存放 UI 测试用例、rust-toolchain固定了构建 lint 所需的 nightly 工具链版本。RisingWave 的 CI 流水线会在常规clippy检查之外单独跑一遍cargo dylint把团队特有的编码约束尤其是错误格式化规范落到实处。背景为什么需要在 Clippy 之外再写自定义 LintRisingWave 是一个用 Rust 编写的大规模流式计算系统代码分布在 src 下的batch、stream、meta、frontend等数十个 crate 中代码量庞大、开发者众多。默认的clippy只能覆盖 rustc 与 Clippy 团队定义的通用规则而 RisingWave 内部有一些项目特有的约定无法用现成 lint 表达例如禁止对错误对象实现了std::error::Error的类型直接使用format!/println!/to_string()格式化因为这样会丢失错误链source chain信息要求统一使用thiserror_ext::AsReport的.as_report()/.to_report_string()来渲染错误报告在tracing事件与anyhow!宏中遇到错误时应使用字段式记录或Context包装而非直接格式化。cargo dylint正是为解决“给 Rust 编译器写自定义 lint 太麻烦”的问题而生的工具它把 lint 实现编译为动态库cdylib由dylint驱动在编译其他 crate 时注入开发者不需要 fork rustc也不需要维护补丁只需编写一个普通的 Rust crate。RisingWave 的lintscrate 就是这样一个 dylint 库。安装 cargo-dylint在使用 RisingWave 的自定义 lint 之前需要先安装两个工具cargo-dylint驱动程序与dylint-link用于链接 lint 动态库的 linker 封装。README 给出的安装命令如下cargo install cargo-dylint dylint-link两个 crate 的版本必须配套。RisingWave 的 CI 镜像中固定安装的是6.0.1版本见 ci/Dockerfile 中的RUN cargo install --locked cargo-dylint6.0.1 dylint-link6.0.1对应的 lints/Cargo.toml 也通过dylint_linting 6.0.1、dylint_testing 6.0.1精确锁定了同一大版本。建议在本地开发时也使用6.0.1或与之兼容的版本避免因版本漂移导致的编译错误。运行 Lints在仓库根目录执行以下命令即可对所有 lint 做一次全量检查cargo dylint --all--all表示对工作区中的所有 crate 执行检查。如果发现编译错误README 给出的建议是重新安装一次cargo-dylint让它与当前 lint crate 依赖的 rustc 内部 API 版本对齐cargo install cargo-dylint dylint-link之所以会反复出现编译问题是因为cargo-dylint本身以及clippy_utils都依赖 rustc 的私有internal、unstableAPI这些 API 随 nightly 版本频繁变动二进制与源码版本错配就会报错。RisingWave 的 CI 中实际执行的检查逻辑比 README 更完整参考 ci/scripts/check-dylint.sh# 1. 列出所有可用 lint为空则报错 output$(cargo dylint list) if [ -z $output ]; then echo ERROR: No lints detected... exit 1 fi # 2. 运行 dylint 检查只把自定义 lint 的警告升级为错误 DYLINT_RUSTFLAGS-A warnings -D rw_warnings cargo dylint --all -- --all-targets --all-features --locked # 3. 运行 lint 自身的 UI 测试 cd lints cargo test cd ..几个关键细节值得注意cargo dylint list会列出当前lintscrate 暴露的全部 lint 名称CI 用它快速校验 lint 库能被正确加载DYLINT_RUSTFLAGS-A warnings -D rw_warnings是 CI 的核心策略只把 RisingWave 自己的rw_warnings组升级为错误deny而rustc/clippy本身产生的警告一律放行。注释里给出了原因——lint 所用的工具链可能与编译 RisingWave 的工具链略有差异rustc 自身的警告可能产生误报而check/clippy的警告已经在check.sh中单独把关了该脚本会关闭sccacheunset RUSTC_WRAPPER因为 dylint 注入机制与编译器缓存包装器不兼容最后在lints目录内执行cargo test来跑 lint 的 UI 测试见下文“测试 Lints”。源码级剖析lints crate 的结构与现有 Lintlintscrate 的目录结构如下lints/ ├── Cargo.toml # 包定义、依赖与 UI 测试 example 声明 ├── README.md # 本文讲解的文档 ├── rust-toolchain # 构建 lint 用的 nightly 版本 ├── src/ │ ├── lib.rs # dylint 库入口注册 lint 与分组 │ ├── format_error.rs # rw::format_error lint 的完整实现 │ └── utils/ │ ├── mod.rs │ ├── path.rs # 路径查找辅助def_path_lookup 宏 │ └── format_args_collector.rs # 收集格式化参数源自 Clippy 源码 └── ui/ ├── format_error.rs # UI 测试输入 └── format_error.stderr # 期望的编译输出Cargo.tomldylint 库的配方lints/Cargo.toml 中几个配置是 dylint 库的关键[package] name lints edition 2024 publish false [package.metadata.rust-analyzer] rustc_private true [lib] crate-type [cdylib] [dependencies] clippy_utils { git https://github.com/rust-lang/rust-clippy, rev 9cadea6247dd } dylint_linting 6.0.1 itertools 0.14 [dev-dependencies] anyhow 1 dylint_testing 6.0.1 thiserror 2 thiserror-ext 0.2 tracing 0.1 [[example]] name format_error path ui/format_error.rs要点解读crate-type [cdylib]是 dylint 库的硬性要求——lint 必须以动态库形式被dylint加载rustc_private true允许代码访问 rustc 的内部 craterustc_ast、rustc_hir、rustc_lint等clippy_utils从 Clippy 仓库以固定 commitrev 9cadea6247dd拉取用于复用 Clippy 内部工具函数如FormatArgsStorage、span_lint_and_help、implements_traitpublish false表明它只服务于本仓库不会发布到 crates.io[[example]]把 ui/format_error.rs 注册为一个 example这是dylint_testing跑 UI 测试的前提。lib.rslint 注册与分组机制src/lib.rs 是 lint 库的入口。开头通过dylint_linting::dylint_library!()宏声明这是一个 dylint 库然后声明了对 rustc 内部 crate 的extern craterustc_ast、rustc_hir、rustc_lint、rustc_session、rustc_span、rustc_data_structures、rustc_lexer。核心的register_lints函数负责注册所有 lint#[unsafe(no_mangle)] pub fn register_lints(_sess: rustc_session::Session, lint_store: mut rustc_lint::LintStore) { // 准备阶段创建 FormatArgsStorage 并注册 early pass 收集格式化参数 let format_args_storage clippy_utils::macros::FormatArgsStorage::default(); let format_args format_args_storage.clone(); lint_store.register_early_pass(move || { Box::new(utils::format_args_collector::FormatArgsCollector::new(format_args.clone())) }); // 实际 lint注册 FORMAT_ERROR 与对应的 late pass lint_store.register_lints([format_error::FORMAT_ERROR]); let format_args format_args_storage.clone(); lint_store .register_late_pass(move |_| Box::new(format_error::FormatError::new(format_args.clone()))); // 注册分组 register_group(lint_store, rw_all, |_| true); register_group(lint_store, rw_warnings, |l| { l.default_level rustc_lint::Level::Warn }); }可以从中提炼出 RisingWave 自定义 lint 的两层流水线架构early passFormatArgsCollector在 AST 解析阶段扫描所有format!系列宏的FormatArgs节点把“源码 span → 格式化参数”的映射写入共享的FormatArgsStorage。该实现直接从 Clippy 仓库复制而来源码注释标明了出处见 src/utils/format_args_collector.rs。它还会用has_span_from_proc_macro识别出由过程宏注入 span 的格式化调用并跳过避免误报late passFormatError在类型检查后的 HIR 阶段借助FormatArgsStorage回溯每一个格式化占位符对应的实际参数表达式判断其类型是否实现了Errortrait从而决定是否报警。分组机制非常巧妙。register_group会遍历 lint store 中所有名字以rw::开头的 lint按谓词过滤后注册为可整体启用的组rw_all包含全部rw::lintrw_warnings只包含默认级别不低于Warn的 lint。这样 CI 中就可以用-D rw_warnings把“团队认为应该修复的所有自定义 lint”一键升级为编译错误。源码注释还提醒分组名用rw_而非rw::是为了规避error[E0602]: unknown lint tool的问题。format_error.rs以 rw::format_error 为例读懂一条 lintsrc/format_error.rs 是当前仓库中唯一一条实际 lint。它的 lint 声明文档declare_tool_lint!给出了完整的语义说明What it does检查对错误直接使用format!的行为。Why is this bad按约定错误类型只保证会格式化自身的消息而不保证能格式化其 source 链上的所有消息。直接格式化错误可能导致信息丢失。Known problems如果你是有意只格式化错误自身的消息可以忽略该 lint。Exampleprintln!(error: {}, err)应改为println!(error: {}, err.as_report())引入thiserror_ext::AsReport。FormatError这个 late pass 在check_expr中覆盖了四大类触发场景对应测试用例 ui/format_error.rs 中的各种写法场景一tracing事件与 span 中的%err/?err通过TRACING_FIELD_DEBUG、TRACING_FIELD_DISPLAY路径匹配tracing::field::debug(..)/tracing::field::display(..)调用再配合macro_backtrace判断是否位于tracing::event宏展开中。例如info!({}, err); // 触发建议改为 error %err.as_report() info!(%err, 233); // 触发 let _ info_span!(span, %err); // 触发 tracing::field::display(err); // 触发给出的建议是consider importingthiserror_ext::AsReportand recording the error as a field witherror %error.as_report()instead场景二format!/println!等格式化宏通过is_format_macro识别所有格式化宏遍历format_args.template中的每个占位符用find_format_arg_expr定位参数表达式。覆盖了{err}、{}、{:#}、{:?}、命名参数{e}、位置参数{0}、err/err引用、err.source().unwrap()、err as dyn Error、Box::new(err)等各种形态let _ format!({err}); let _ format!({}, err); let _ format!({:?}, err as dyn Error); let _ format!({}, Box::new(err.clone())); println!({}, err);如果参数同时位于anyhow!宏中还会细分处理见下。场景三anyhow!宏中的错误通过ANYHOW_ANYHOW路径识别anyhow!宏并依据模板长度区分两种子场景模板只有单个占位符如anyhow!({}, err)提示直接包装anyhow::anyhow!(..)见check_fmt_arg_in_anyhow_error模板包含附加消息如anyhow!(some error occurred: {}, err)提示改用anyhow::Context::(with_)context把消息附加到错误上并保留 source 链见check_fmt_arg_in_anyhow_context。场景四err.to_string()通过type_dependent_def_id判断方法是否来自ToStringtraitcx.tcx.is_diagnostic_item(ToString, trait_id)对err.to_string()、(err.clone()).to_string()、(err).to_string()、甚至err.to_string().to_string()都会报警建议改用.to_report_string()。类型判定逻辑check_arg函数是这条 lint 的灵魂先peel_refs()剥离引用层然后用implements_trait检查是否实现std::error::Erroranyhow::Error并不实现Errortrait测试用例中特意注释了这一点因此需单独用ANYHOW_ERROR.matches_ty匹配thiserror_ext::Report也需要单独分支处理避免对已修复的代码重复报警。两条值得留意的豁免规则测试代码#[cfg(test)]或测试函数内不报警is_in_cfg_test/is_in_test_functionthiserror的#[error(...)]属性中的格式化不报警注释给出的理由是这类消息可以由thiserror_ext::Report在格式化时归一化。测试用例末尾#[derive(thiserror::Error)] #[error(my io error: {0})]验证了这一豁免用例注释里的TODO也如实标出了当前未覆盖的边界如Boxdyn Error直接格式化、Box::new(anyhow_err)等展现出这个 lint 仍在演进中。src/utils/path.rs中的def_path_lookup!宏则提供了一套路径查找基础设施把tracing_core::field::debug这类字符串路径拆分成符号数组构建PathLookup并支持区分Value/Macro/Type三种命名空间PathNS。注释里提示调试时可以打印path.get(cx)确认路径解析是否正确。新增一条 Lint 的完整流程根据 README新增 lint 只需三步在src目录新增文件用declare_tool_lint!声明 lint建议命名为rw::something以便分组编写 lint pass 实现在 src/lib.rs 的register_lints中注册把 lint 加入lint_store.register_lints([...])并register_late_pass/register_early_pass对应的 pass若新 lint 默认级别是Warn或以上它会自动进入rw_warnings组编写 UI 测试见下一节然后运行cargo test验证。若新 lint 需要访问format!的参数展开信息可复用FormatArgsStorage与FormatArgsCollector这套已就绪的基础设施需要识别特定类型/宏时可参照def_path_lookup!声明路径常量。测试 LintsUI 测试机制RisingWave 用 Clippy 风格的UI 测试来验证 lint 行为工作流如下在ui目录创建测试源文件例如 ui/format_error.rs在 Cargo.toml 中把它声明为 example[[example]] name format_error path ui/format_error.rs在对应 lint 源文件中添加测试函数见 src/format_error.rs 末尾#[test] fn ui() { dylint_testing::ui_test_example(env!(CARGO_PKG_NAME), format_error); }运行cargo test。dylint_testing会把 example 编译一遍将产生的编译输出与 ui/format_error.stderr 中的期望输出逐行比对。从.stderr文件可以看到当前format_error用例共产生47 条警告每条都包含精确的行列号、help建议和 lint 名称#[warn(rw::format_error)] on by default。新增或修改 lint 行为后如果预期输出变了需要同步更新.stderr通常通过cargo test生成的建议输出人工确认后回填。VS Code 集成rust-analyzer 开发环境开发 lint 时建议启用 rust-analyzer 的rustc_private支持因为 lint 代码依赖 rustc 内部 crate。操作方式将.vscode/settings.json.example复制为.vscode/settings.json重新加载窗口后rust-analyzer 即能解析rustc_*crate 的符号提供跳转与补全。此外 lints/Cargo.toml 中的[package.metadata.rust-analyzer] rustc_private true也从包元数据层面开启了这一支持。升级工具链Bump Toolchain的注意事项这是维护lintscrate 时最容易踩坑的部分。lints目录下的 rust-toolchain当前为nightly-2026-06-11包含llvm-tools-preview与rustc-dev组件有两个作用构建 lint 本身由dylint用来编译 RisingWave 本体而不是根目录的rust-toolchain。因此选择的工具链版本需要满足两个约束README 原文与根目录 rust-toolchain 的版本足够接近保证 RisingWave 能正常编译不必完全一致与 Clippy 仓库中clippy_utils对应的工具链足够接近因为clippy_utils依赖 rustc 内部的不稳定 API。其深层原因是clippy_utils依赖 rustc 内部 API当 rustc 发生破坏性变更时rust 仓库内的 Clippy 会同步更新随后每两周从 rust 仓库同步回 Clippy 独立仓库。理想做法是直接使用与根目录 nightly 版本对应的 rust 仓库中的clippy_utils但 rust 仓库体量太大难以直接依赖——README 也提到可以考虑“把代码拷贝出来”来绕开这一问题。升级时可以借助以下信息定位合适版本README 给出的参考来源本文按仓库内现有信息整理最新版cargo-dylint模板使用的工具链trailofbits/dylint 仓库internal/template/rust-toolchain最新版 Clippy 使用的工具链rust-lang/rust-clippy 仓库rust-toolchainrust-lang/rust-clippy仓库中clippy-utils依赖对应的最新 commit hash。升级后务必重新运行一遍 lints 验证确保在新工具链下 lint 仍能正常编译、cargo dylint --all无回归。仓库内两条硬性提醒也值得注意lints/Cargo.toml中注释要求“升级版本前阅读 README并同步更新 ci/Dockerfile 中的版本”clippy_utils的rev当前为9cadea6247dd也需要随工具链一起评估是否更新。在 CI 与日常开发中的落地方式CI 集成ci/scripts/check-dylint.sh是 lint 检查的入口通过cargo dylint list校验加载、DYLINT_RUSTFLAGS-A warnings -D rw_warnings执行检查、cargo test跑 UI 测试CI 镜像在 ci/Dockerfile 中预装cargo-dylint6.0.1 dylint-link6.0.1保证环境一致、可复现。本地开发在仓库根目录运行cargo dylint --all对全工作区做一次检查编写或修改 lint 后在lints目录运行cargo test验证 UI 测试。小结RisingWave 的lintscrate 展示了在大型 Rust 仓库中落地“团队自定义代码规范”的完整工程范式以cargo dylint为运行时载体、以dylint_linting/clippy_utils为构建基础设施通过rw_all/rw_warnings分组实现“一键 deny”通过 UI 测试保障 lint 自身质量并借助独立的rust-toolchain与 CI 脚本实现可复现的检查流程。对于想要在自家 Rust 工程中引入类似机制比如禁止误用格式化、强制统一错误报告风格的团队这套模式可以直接复用——安装cargo-dylint、声明一个 cdylib crate、注册 lint、补一组 UI 测试即可让团队约定在编译期自动执行。赞分享数据库流处理后端数据工程【免费下载链接】risingwaveEvent streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale.项目地址https://gitcode.com/gh_mirrors/ri/risingwave点击查看免费下载相关推荐pnpm 的 Rust 代码风格指南基于 Clippy、perfectionist 与 Dylint 的工程化规范实践pnpm 的 Rust 代码风格指南基于 Clippy、perfectionist 与 Dylint 的工程化规范实践 导读 本文以 pnpm/CODE_ST包管理器开发工具CLI企业级Rust代码规范落地rust-clippy自定义规则开发指南企业级Rust代码规范落地rust clippy自定义规则开发指南 Rust作为系统级编程语言凭借内存安全和高性能特性在企业级开发中得到广泛应用。然而随着静态分析代码质量开发工具彻底解决Rust代码质量问题Clippy检查规则与自定义lint全指南彻底解决Rust代码质量问题Clippy检查规则与自定义lint全指南 你是否还在为Rust项目中的隐藏bug和不规范代码头疼作为一门注重安全与性能的语言编程语言编译器语言运行时标准库上一篇Genkit JS Agent Artifacts 实战用 artifacts() 中间件让 Agent 产出与管理命名交付物Beta下一篇GraphiQL 5.x 演进全解析Monaco 迁移、API 重构与插件系统变革基于 graphiql 包 CHANGELOG 的深度解读创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
