同一Lib Crate中仅向二进制暴露代码的Rust死代码分析问题

我们的项目库中，许多Rust crate同时包含lib.rs和main.rs，这会让二进制程序被当作自身crate的“外部”使用者。这类crate通常会对外暴露配置结构和一组消费该配置以启动特定工作进程的公共函数，典型结构如下：

# Cargo.toml
[package]
name = "foo"
version = "0.1.0"
edition = "2021"

/// src/config.rs
#[derive(Debug)]
pub struct AppConfig {
    pub dead_code: String,
}

/// src/lib.rs
pub mod config;

pub fn run(config: config::AppConfig) {
    println!("{config:?}")
}

/// src/main.rs
use foo::config::AppConfig;
use foo::run;

fn main() {
    // 实际代码中从文件加载配置
    let config = AppConfig{ dead_code: "never read".into() };
    run(config)
}

在这个场景下，死代码分析无法检测到配置中的未使用字段，因为这些字段被视为公共API的一部分——哪怕crate自身并未读取它们，也会被认为可能被外部使用者调用。但我们的实际情况是没有外部使用者，因此需要找到方法解决这个问题，以启用死代码检测。

目前我想到三种可行方案：

• 方案1：将main()的内容封装到库中的一个公共函数里，然后将AppConfig设为私有或crate级可见。该方案有效，但二进制程序会沦为仅导入并调用无参函数的冗余部分。
• 方案2：将AppConfig设为私有/crate级可见，同时暴露一个用于加载配置的包装器，将该公共包装器作为公共函数的参数。
• 方案3：在main.rs中添加use config，并使用crate::config替代foo::config。该方案看似可行，但实践中需要为二进制程序添加大量模块，且若部分模块仅对库暴露、不对二进制暴露，会导致构建时的导入冲突，需在两处维护模块，易出错。

目前我采用方案2，但想了解这是否是处理此类场景的正确方式——此前已有不少因属于“仅向同一crate内二进制暴露的公共API”而未及时检测到死代码的情况。另外，是否存在Clippy专属的方式，可将这类API标记为私有或按私有处理？

本问题与《Dead code warning with multiple binaries?》的情况相反。

内容的提问来源于stack exchange，提问作者sukhmel