处理传递给程序宏的编译时相关文本文件的正确方法

Posted 2023-02-19

【中文标题】处理传递给程序宏的编译时相关文本文件的正确方法

【英文标题】：Proper way to handle a compile-time relevant text file passed to a procedural macro

【发布时间】：2020-03-05 04:16:04

【问题描述】：

我需要将文本文件或文本文件的内容传递给程序宏，以便程序宏在编译时根据该文本文件的内容进行操作。也就是说，文本文件配置了宏的输出。这个用例是定义一个寄存器映射的文件，宏构建到一个库中。

第二个要求是 Cargo 正确处理文本文件，这样对文本文件的更改会触发重新编译，就像对源文件的更改触发重新编译一样。

我最初的想法是使用include_str! 宏创建一个static 字符串。这解决了第二个要求，但我看不到如何将 that 传递给宏 - 那时我只有要传递的字符串的标识符：

use my_macro_lib::my_macro;
static MYSTRING: &'static str = include_str!("myfile");
my_macro!(MYSTRING); // Not the string itself!

我可以用字符串文字中的文件名将字符串传递给宏，然后在宏内打开文件：

my_macro!("myfile");

此时我有两个问题：

为了获取文件的路径，如何获取调用函数的路径并不明显。我最初认为这将通过令牌 Span 暴露出来，但似乎一般不会（也许我遗漏了什么？）。 如何使文件 make Cargo 在更改时触发重新编译并不明显。我不得不强制这样做的一个想法是在宏的输出中添加一个include_str!("myfile")，这有望导致编译器知道“myfile”，但这有点麻烦。

有什么方法可以做我想做的事吗？也许要么通过某种方式获取外部创建的宏内部的字符串内容，要么可靠地获取调用 rust 文件的路径（然后使 Cargo 正确处理更改）。

顺便说一句，我读过很多地方告诉我我无法访问宏中变量的内容，但在我看来，这正是 quote 宏对 @ 所做的事情987654336@。这是如何工作的？

【问题讨论】：

我需要将文本文件传递给程序宏 — sounds how an XY problem starts。

就像，所有这些听起来都应该是一个构建脚本。例如。 How do I generate a text file during compile time and include its content in the output?; How to create a static string at compile time; How can I override a constant via a compiler option?.

A concrete example

@shepmaster 将其作为构建脚本会破坏使用文件名调用宏的人体工程学，并且需要每次调用都添加构建脚本（我将有几个用于我的不同部分代码库）。为了比较，我总是可以将文本文件的全部内容放在宏的参数中，但是在编辑时会丢失语法突出显示等等（它将是一个 YAML 文档）。

@Shepmaster 只要可以做其他事情，这不是一个严格的要求（所以你的 XY 问题点是合理的），但我已经接近图书馆的人机工程学了，我'我正在努力看看我是否真的可以完全实现我正在尝试做的事情。

【参考方案1】：

所以事实证明，这基本上可以按照我希望使用稳定编译器的方式实现。

如果我们接受我们需要相对于 crate 根工作，我们可以这样定义我们的路径。

在宏代码中，std::env::current_dir() 将返回当前工作目录作为包含调用站点的 crate 的根目录。这意味着，即使宏调用位于某个 crate 层次结构中，它仍然会返回在宏调用位置有意义的路径。

以下示例宏基本上可以满足我的需要。为简洁起见，它并非旨在正确处理错误：

extern crate proc_macro;

use quote::quote;
use proc_macro::TokenStream;
use syn::parse::Parse, ParseStream, Result;
use syn;
use std;
use std::fs::File;
use std::io::Read;

#[derive(Debug)]
struct FileName 
    filename: String,


impl Parse for FileName 

    fn parse(input: ParseStream) -> Result<Self> 
        let lit_file: syn::LitStr = input.parse()?;
        Ok(Self  filename: lit_file.value() )
    


#[proc_macro]
pub fn my_macro(input: TokenStream) -> TokenStream 
    let input = syn::parse_macro_input!(input as FileName);

    let cwd = std::env::current_dir().unwrap();

    let file_path = cwd.join(&input.filename);
    let file_path_str = format!("", file_path.display());

    println!("path: ", file_path.display());

    let mut file = File::open(file_path).unwrap();
    let mut contents = String::new();
    file.read_to_string(&mut contents).unwrap();

    println!("contents: :?", contents);

    let result = quote!(

        const FILE_STR: &'static str = include_str!(#file_path_str);
        pub fn foo() -> bool 
            println!("Hello");
            true
        
    );

    TokenStream::from(result)

可以调用

my_macro!("mydir/myfile");

mydir 是调用 crate 根目录中的一个目录。

这使用了在宏输出中使用include_str!() 的技巧来导致对myfile 的更改进行重建。这是必要的，并且符合预期。如果它从未实际使用过，我希望它会被优化。

我很想知道这种方法是否会在任何情况下失效。

与我最初的问题相关，当前 nightly 在 Span 上实现 source_file() 方法。这可能是实现上述内容的更好方法，但我宁愿坚持使用稳定。对此的跟踪问题是here。

编辑： 当包在工作空间中时，上述实现会失败，此时当前工作目录是工作空间根目录，而不是 crate 根目录。这很容易解决，如下所示（插入在 cwd 和 file_path 声明之间）。

    let mut cwd = std::env::current_dir().unwrap();

    let cargo_path = cwd.join("Cargo.toml");
    let mut cargo_file = File::open(cargo_path).unwrap();
    let mut cargo_contents = String::new();
    cargo_file.read_to_string(&mut cargo_contents).unwrap();

    // Use a simple regex to detect the suitable tag in the toml file. Much 
    // simpler than using the toml crate and probably good enough according to
    // the workspace RFC.
    let cargo_re = regex::Regex::new(r"(?m)^\[workspace\][ \t]*$").unwrap();

    let workspace_path = match cargo_re.find(&cargo_contents) 
        Some(val) => std::env::var("CARGO_PKG_NAME"),
        None => "".to_string()
    ;

    let file_path = cwd.join(workspace_path).join(input.filename);
    let file_path_str = format!("", file_path.display());