构建foo crate时生成proc-macro展开版代码的实现方案咨询

可行性分析 #

这个需求完全可行，尽管生成100%可编译的展开代码存在局限性（你已了解相关免责声明），但通过结合Cargo构建钩子、宏展开工具和代码过滤逻辑，可以满足你提出的所有核心需求，尤其是聚焦自身proc宏展开、Git提交、LSP支持及cfg切换的功能。

实现方案 #

核心思路是通过build.rs构建脚本触发宏展开，过滤掉无关依赖的代码，生成保持原结构的展开源码目录，再通过条件编译切换使用原代码或展开代码。

1. 集成宏展开逻辑到构建流程

在foo crate中添加build.rs，调用cargo expand来获取自身proc宏的展开结果：

• 利用cargo expand --lib --exclude-deps <依赖名>参数，仅展开foo自身的代码，排除标准库和其他第三方依赖的宏展开；
• 通过std::process::Command在构建脚本中执行该命令，捕获输出的展开代码。

示例build.rs片段：

use std::fs;
use std::path::Path;
use std::process::Command;

fn main() {
    // 执行cargo expand，仅展开foo的lib目标，排除所有依赖（含std）
    let output = Command::new("cargo")
        .args([
            "expand",
            "--lib",
            "--exclude-deps", "all",
        ])
        .output()
        .expect("Failed to execute cargo expand");

    let expanded_code = String::from_utf8(output.stdout)
        .expect("cargo expand输出非UTF-8格式");

    // 创建展开代码的目录结构
    let expanded_root = Path::new("expanded/src");
    fs::create_dir_all(expanded_root).expect("无法创建展开代码目录");

    // 若原项目有多模块，可通过syn库解析AST拆分代码到对应文件，此处简化为写入lib.rs
    fs::write(expanded_root.join("lib.rs"), expanded_code)
        .expect("写入展开代码失败");

    // 监听原代码和宏crate变化，自动重新生成
    println!("cargo:rerun-if-changed=src");
    println!("cargo:rerun-if-changed=../foo_macros");
}

2. 过滤无关代码

通过cargo expand的--exclude-deps参数可以精准控制要排除的依赖：

• 用--exclude-deps all排除所有第三方依赖和标准库；
• 若需要保留foo_macros的定义（仅展开其宏调用），可指定--exclude-deps std,其他依赖名。

如果需要更精细的过滤（比如移除特定模块），可以用syn库解析展开后的代码AST，删除无关节点后再生成文件。

3. 实现条件编译切换

在foo的src/lib.rs中添加条件导入逻辑，通过cfg标志切换使用原代码或展开代码：

// 原代码入口，可将原业务代码移至src/original.rs
#[cfg(not(feature = "use-expanded"))]
mod original;
#[cfg(not(feature = "use-expanded"))]
pub use original::*;

// 展开代码入口
#[cfg(feature = "use-expanded")]
mod expanded {
    pub use crate::expanded_src::*;
}
#[cfg(feature = "use-expanded")]
pub use expanded::*;

同时在foo/Cargo.toml中添加对应的feature：

[features]
use-expanded = []

使用时通过cargo build --feature use-expanded切换为展开代码，默认使用原代码。

满足你的额外需求 #

1. 提交至Git：将expanded/目录加入Git仓库即可，构建脚本每次生成完整的展开代码，确保代码可追踪；
2. 仅展开自身宏：通过--exclude-deps参数过滤依赖，结合AST解析可进一步精准控制；
3. LSP导航支持：将expanded/目录添加到Rust Analyzer的工作区索引（可通过.rust-analyzer.toml配置），编辑器即可识别展开代码并提供导航功能；
4. 手动修改迭代：直接修改expanded/src/下的代码，通过use-expanded feature编译测试，再反向调整foo_macros中的宏逻辑，循环迭代；
5. cfg切换：通过上述feature配置，一键切换原代码/展开代码的编译路径。

相关先例 #

• 不少proc宏开发项目会用类似逻辑生成展开代码用于调试，比如async-trait、derive_more等库的测试套件；
• 部分Rust工具链项目会集成宏展开逻辑来提供代码分析支持，你可以参考其底层实现来优化自己的生成流程。

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