为什么必须在proc-macro crate中定义proc-macros? [英] Why do proc-macros have to be defined in proc-macro crate?

问题描述

我正在尝试为我的特征创建一个派生宏，以简化某些内容.

我遇到了一些问题:

the `#[proc_macro_derive]` attribute is only usable with crates of the `proc-macro` crate type

，然后进行小修正proc-macro=true:

proc-macro` crate types cannot export any items other than functions tagged with `#[proc_macro_derive]` currently
functions tagged with `#[proc_macro_derive]` must currently reside in the root of the crate`

这种行为的原因是什么?

解决方案

过程宏与代码中的常规依赖项根本不同.普通库只是链接到您的代码中，而过程宏实际上是编译器 plugin .

考虑交叉编译的情况:您正在Linux机器上工作，但是正在构建WASM项目.

• 普通板条箱将被交叉编译，生成WASM代码并与其余板条箱链接.
• proc-macro板条箱必须在本地编译，在这种情况下为Linux代码，并与当前的编译器运行时(稳定，beta，夜间)链接，并在编译板条箱的实际位置时由编译器本身加载.它将不链接到其余的板条箱(不同的架构！).

而且由于编译流程不同，所以包装箱类型也必须不同，这就是为什么需要proc_macro=true的原因.

关于此限制:

除了用#[proc_macro_derive]

标记的功能外，

proc-macro板条箱类型无法导出任何项目

好吧，由于proc-macro板条箱是由编译器加载的，没有链接到其余板条箱，因此，从该板条箱导出的任何非proc-macro宏代码都是无用的.

请注意，错误消息不准确，因为您还可以使用#[proc_macro]导出函数tagget.

关于其他限制:

标记为#[proc_macro_derive]的功能当前必须位于板条箱的根部

恕我直言，目前不支持在嵌套模块中添加proc_macro或proc_macro_derive项，并且似乎没有什么用处.

I was trying to create a derive macro for my trait, to simplify some stuff.

I've encountered some problems:

the `#[proc_macro_derive]` attribute is only usable with crates of the `proc-macro` crate type

and, after the small fix proc-macro=true:

proc-macro` crate types cannot export any items other than functions tagged with `#[proc_macro_derive]` currently
functions tagged with `#[proc_macro_derive]` must currently reside in the root of the crate`

What is the reason for this behaviour?

解决方案

Procedural macros are fundamentally different from normal dependencies in your code. A normal library is just linked into your code, but a procedural macro is actually a compiler plugin.

Consider the case of cross-compiling: you are working on a Linux machine, but building a WASM project.

• A normal crate will be cross-compiled, generate WASM code and linked with the rest of the crates.
• A proc-macro crate must be compiled natively, in this case to Linux code, linked with the current compiler runtime (stable, beta, nightly) and be loaded by the compiler itself when compiling the crates where it is actually used. It will not be linked to the rest of the crates (different architecture!).

And since the compilation flow is different, the crate type must also be different, that is why the proc_macro=true is needed.

About this restriction:

proc-macro crate types cannot export any items other than functions tagged with #[proc_macro_derive]

Well, since the proc-macro crate is loaded by the compiler, not linked to the rest of your crates, any non-proc-macro code you export from this crate would be useless.

Note that the error message is inexact, as you can also export functions tagget with #[proc_macro].

And about this other restriction:

functions tagged with #[proc_macro_derive] must currently reside in the root of the crate

Adding proc_macro or proc_macro_derive items in nested modules is not currently supported, and does not seem to be particularly useful, IMHO.

这篇关于为什么必须在proc-macro crate中定义proc-macros?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！