feat: added cleanscript
This commit is contained in:
485
ch20/ch20-05-macros.html
Normal file
485
ch20/ch20-05-macros.html
Normal file
@@ -0,0 +1,485 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>Macros</title>
|
||||
</head>
|
||||
<body>
|
||||
<h2 id="macros"><a class="header" href="#macros">Macros</a></h2>
|
||||
<p>We’ve used macros like <code>println!</code> throughout this book, but we haven’t fully
|
||||
explored what a macro is and how it works. The term <em>macro</em> refers to a family
|
||||
of features in Rust—declarative macros with <code>macro_rules!</code> and three kinds of
|
||||
procedural macros:</p>
|
||||
<ul>
|
||||
<li>Custom <code>#[derive]</code> macros that specify code added with the <code>derive</code> attribute
|
||||
used on structs and enums</li>
|
||||
<li>Attribute-like macros that define custom attributes usable on any item</li>
|
||||
<li>Function-like macros that look like function calls but operate on the tokens
|
||||
specified as their argument</li>
|
||||
</ul>
|
||||
<p>We’ll talk about each of these in turn, but first, let’s look at why we even
|
||||
need macros when we already have functions.</p>
|
||||
<h3 id="the-difference-between-macros-and-functions"><a class="header" href="#the-difference-between-macros-and-functions">The Difference Between Macros and Functions</a></h3>
|
||||
<p>Fundamentally, macros are a way of writing code that writes other code, which
|
||||
is known as <em>metaprogramming</em>. In Appendix C, we discuss the <code>derive</code>
|
||||
attribute, which generates an implementation of various traits for you. We’ve
|
||||
also used the <code>println!</code> and <code>vec!</code> macros throughout the book. All of these
|
||||
macros <em>expand</em> to produce more code than the code you’ve written manually.</p>
|
||||
<p>Metaprogramming is useful for reducing the amount of code you have to write and
|
||||
maintain, which is also one of the roles of functions. However, macros have
|
||||
some additional powers that functions don’t have.</p>
|
||||
<p>A function signature must declare the number and type of parameters the
|
||||
function has. Macros, on the other hand, can take a variable number of
|
||||
parameters: We can call <code>println!("hello")</code> with one argument or
|
||||
<code>println!("hello {}", name)</code> with two arguments. Also, macros are expanded
|
||||
before the compiler interprets the meaning of the code, so a macro can, for
|
||||
example, implement a trait on a given type. A function can’t, because it gets
|
||||
called at runtime and a trait needs to be implemented at compile time.</p>
|
||||
<p>The downside to implementing a macro instead of a function is that macro
|
||||
definitions are more complex than function definitions because you’re writing
|
||||
Rust code that writes Rust code. Due to this indirection, macro definitions are
|
||||
generally more difficult to read, understand, and maintain than function
|
||||
definitions.</p>
|
||||
<p>Another important difference between macros and functions is that you must
|
||||
define macros or bring them into scope <em>before</em> you call them in a file, as
|
||||
opposed to functions you can define anywhere and call anywhere.</p>
|
||||
<!-- Old headings. Do not remove or links may break. -->
|
||||
<p><a id="declarative-macros-with-macro_rules-for-general-metaprogramming"></a></p>
|
||||
<h3 id="declarative-macros-for-general-metaprogramming"><a class="header" href="#declarative-macros-for-general-metaprogramming">Declarative Macros for General Metaprogramming</a></h3>
|
||||
<p>The most widely used form of macros in Rust is the <em>declarative macro</em>. These
|
||||
are also sometimes referred to as “macros by example,” “<code>macro_rules!</code> macros,”
|
||||
or just plain “macros.” At their core, declarative macros allow you to write
|
||||
something similar to a Rust <code>match</code> expression. As discussed in Chapter 6,
|
||||
<code>match</code> expressions are control structures that take an expression, compare the
|
||||
resultant value of the expression to patterns, and then run the code associated
|
||||
with the matching pattern. Macros also compare a value to patterns that are
|
||||
associated with particular code: In this situation, the value is the literal
|
||||
Rust source code passed to the macro; the patterns are compared with the
|
||||
structure of that source code; and the code associated with each pattern, when
|
||||
matched, replaces the code passed to the macro. This all happens during
|
||||
compilation.</p>
|
||||
<p>To define a macro, you use the <code>macro_rules!</code> construct. Let’s explore how to
|
||||
use <code>macro_rules!</code> by looking at how the <code>vec!</code> macro is defined. Chapter 8
|
||||
covered how we can use the <code>vec!</code> macro to create a new vector with particular
|
||||
values. For example, the following macro creates a new vector containing three
|
||||
integers:</p>
|
||||
<pre class="playground"><code class="language-rust edition2024"><span class="boring">#![allow(unused)]
|
||||
</span><span class="boring">fn main() {
|
||||
</span>let v: Vec<u32> = vec![1, 2, 3];
|
||||
<span class="boring">}</span></code></pre>
|
||||
<p>We could also use the <code>vec!</code> macro to make a vector of two integers or a vector
|
||||
of five string slices. We wouldn’t be able to use a function to do the same
|
||||
because we wouldn’t know the number or type of values up front.</p>
|
||||
<p>Listing 20-35 shows a slightly simplified definition of the <code>vec!</code> macro.</p>
|
||||
<figure class="listing" id="listing-20-35">
|
||||
<span class="file-name">Filename: src/lib.rs</span>
|
||||
<pre><code class="language-rust noplayground">#[macro_export]
|
||||
macro_rules! vec {
|
||||
( $( $x:expr ),* ) => {
|
||||
{
|
||||
let mut temp_vec = Vec::new();
|
||||
$(
|
||||
temp_vec.push($x);
|
||||
)*
|
||||
temp_vec
|
||||
}
|
||||
};
|
||||
}</code></pre>
|
||||
<figcaption><a href="#listing-20-35">Listing 20-35</a>: A simplified version of the <code>vec!</code> macro definition</figcaption>
|
||||
</figure>
|
||||
<section class="note" aria-role="note">
|
||||
<p>Note: The actual definition of the <code>vec!</code> macro in the standard library
|
||||
includes code to pre-allocate the correct amount of memory up front. That code
|
||||
is an optimization that we don’t include here, to make the example simpler.</p>
|
||||
</section>
|
||||
<p>The <code>#[macro_export]</code> annotation indicates that this macro should be made
|
||||
available whenever the crate in which the macro is defined is brought into
|
||||
scope. Without this annotation, the macro can’t be brought into scope.</p>
|
||||
<p>We then start the macro definition with <code>macro_rules!</code> and the name of the
|
||||
macro we’re defining <em>without</em> the exclamation mark. The name, in this case
|
||||
<code>vec</code>, is followed by curly brackets denoting the body of the macro definition.</p>
|
||||
<p>The structure in the <code>vec!</code> body is similar to the structure of a <code>match</code>
|
||||
expression. Here we have one arm with the pattern <code>( $( $x:expr ),* )</code>,
|
||||
followed by <code>=></code> and the block of code associated with this pattern. If the
|
||||
pattern matches, the associated block of code will be emitted. Given that this
|
||||
is the only pattern in this macro, there is only one valid way to match; any
|
||||
other pattern will result in an error. More complex macros will have more than
|
||||
one arm.</p>
|
||||
<p>Valid pattern syntax in macro definitions is different from the pattern syntax
|
||||
covered in Chapter 19 because macro patterns are matched against Rust code
|
||||
structure rather than values. Let’s walk through what the pattern pieces in
|
||||
Listing 20-29 mean; for the full macro pattern syntax, see the <a href="../reference/macros-by-example.html">Rust
|
||||
Reference</a>.</p>
|
||||
<p>First, we use a set of parentheses to encompass the whole pattern. We use a
|
||||
dollar sign (<code>$</code>) to declare a variable in the macro system that will contain
|
||||
the Rust code matching the pattern. The dollar sign makes it clear this is a
|
||||
macro variable as opposed to a regular Rust variable. Next comes a set of
|
||||
parentheses that captures values that match the pattern within the parentheses
|
||||
for use in the replacement code. Within <code>$()</code> is <code>$x:expr</code>, which matches any
|
||||
Rust expression and gives the expression the name <code>$x</code>.</p>
|
||||
<p>The comma following <code>$()</code> indicates that a literal comma separator character
|
||||
must appear between each instance of the code that matches the code in <code>$()</code>.
|
||||
The <code>*</code> specifies that the pattern matches zero or more of whatever precedes
|
||||
the <code>*</code>.</p>
|
||||
<p>When we call this macro with <code>vec![1, 2, 3];</code>, the <code>$x</code> pattern matches three
|
||||
times with the three expressions <code>1</code>, <code>2</code>, and <code>3</code>.</p>
|
||||
<p>Now let’s look at the pattern in the body of the code associated with this arm:
|
||||
<code>temp_vec.push()</code> within <code>$()*</code> is generated for each part that matches <code>$()</code>
|
||||
in the pattern zero or more times depending on how many times the pattern
|
||||
matches. The <code>$x</code> is replaced with each expression matched. When we call this
|
||||
macro with <code>vec![1, 2, 3];</code>, the code generated that replaces this macro call
|
||||
will be the following:</p>
|
||||
<pre><code class="language-rust ignore">{
|
||||
let mut temp_vec = Vec::new();
|
||||
temp_vec.push(1);
|
||||
temp_vec.push(2);
|
||||
temp_vec.push(3);
|
||||
temp_vec
|
||||
}</code></pre>
|
||||
<p>We’ve defined a macro that can take any number of arguments of any type and can
|
||||
generate code to create a vector containing the specified elements.</p>
|
||||
<p>To learn more about how to write macros, consult the online documentation or
|
||||
other resources, such as <a href="https://veykril.github.io/tlborm/">“The Little Book of Rust Macros”</a> started by
|
||||
Daniel Keep and continued by Lukas Wirth.</p>
|
||||
<h3 id="procedural-macros-for-generating-code-from-attributes"><a class="header" href="#procedural-macros-for-generating-code-from-attributes">Procedural Macros for Generating Code from Attributes</a></h3>
|
||||
<p>The second form of macros is the procedural macro, which acts more like a
|
||||
function (and is a type of procedure). <em>Procedural macros</em> accept some code as
|
||||
an input, operate on that code, and produce some code as an output rather than
|
||||
matching against patterns and replacing the code with other code as declarative
|
||||
macros do. The three kinds of procedural macros are custom <code>derive</code>,
|
||||
attribute-like, and function-like, and all work in a similar fashion.</p>
|
||||
<p>When creating procedural macros, the definitions must reside in their own crate
|
||||
with a special crate type. This is for complex technical reasons that we hope
|
||||
to eliminate in the future. In Listing 20-36, we show how to define a
|
||||
procedural macro, where <code>some_attribute</code> is a placeholder for using a specific
|
||||
macro variety.</p>
|
||||
<figure class="listing" id="listing-20-36">
|
||||
<span class="file-name">Filename: src/lib.rs</span>
|
||||
<pre><code class="language-rust ignore">use proc_macro::TokenStream;
|
||||
|
||||
#[some_attribute]
|
||||
pub fn some_name(input: TokenStream) -> TokenStream {
|
||||
}</code></pre>
|
||||
<figcaption><a href="#listing-20-36">Listing 20-36</a>: An example of defining a procedural macro</figcaption>
|
||||
</figure>
|
||||
<p>The function that defines a procedural macro takes a <code>TokenStream</code> as an input
|
||||
and produces a <code>TokenStream</code> as an output. The <code>TokenStream</code> type is defined by
|
||||
the <code>proc_macro</code> crate that is included with Rust and represents a sequence of
|
||||
tokens. This is the core of the macro: The source code that the macro is
|
||||
operating on makes up the input <code>TokenStream</code>, and the code the macro produces
|
||||
is the output <code>TokenStream</code>. The function also has an attribute attached to it
|
||||
that specifies which kind of procedural macro we’re creating. We can have
|
||||
multiple kinds of procedural macros in the same crate.</p>
|
||||
<p>Let’s look at the different kinds of procedural macros. We’ll start with a
|
||||
custom <code>derive</code> macro and then explain the small dissimilarities that make the
|
||||
other forms different.</p>
|
||||
<!-- Old headings. Do not remove or links may break. -->
|
||||
<p><a id="how-to-write-a-custom-derive-macro"></a></p>
|
||||
<h3 id="custom-derive-macros"><a class="header" href="#custom-derive-macros">Custom <code>derive</code> Macros</a></h3>
|
||||
<p>Let’s create a crate named <code>hello_macro</code> that defines a trait named
|
||||
<code>HelloMacro</code> with one associated function named <code>hello_macro</code>. Rather than
|
||||
making our users implement the <code>HelloMacro</code> trait for each of their types,
|
||||
we’ll provide a procedural macro so that users can annotate their type with
|
||||
<code>#[derive(HelloMacro)]</code> to get a default implementation of the <code>hello_macro</code>
|
||||
function. The default implementation will print <code>Hello, Macro! My name is TypeName!</code> where <code>TypeName</code> is the name of the type on which this trait has
|
||||
been defined. In other words, we’ll write a crate that enables another
|
||||
programmer to write code like Listing 20-37 using our crate.</p>
|
||||
<figure class="listing" id="listing-20-37">
|
||||
<span class="file-name">Filename: src/main.rs</span>
|
||||
<pre><code class="language-rust ignore does_not_compile">use hello_macro::HelloMacro;
|
||||
use hello_macro_derive::HelloMacro;
|
||||
|
||||
#[derive(HelloMacro)]
|
||||
struct Pancakes;
|
||||
|
||||
fn main() {
|
||||
Pancakes::hello_macro();
|
||||
}</code></pre>
|
||||
<figcaption><a href="#listing-20-37">Listing 20-37</a>: The code a user of our crate will be able to write when using our procedural macro</figcaption>
|
||||
</figure>
|
||||
<p>This code will print <code>Hello, Macro! My name is Pancakes!</code> when we’re done. The
|
||||
first step is to make a new library crate, like this:</p>
|
||||
<pre><code class="language-console">$ cargo new hello_macro --lib
|
||||
</code></pre>
|
||||
<p>Next, in Listing 20-38, we’ll define the <code>HelloMacro</code> trait and its associated
|
||||
function.</p>
|
||||
<figure class="listing" id="listing-20-38">
|
||||
<span class="file-name">Filename: src/lib.rs</span>
|
||||
<pre><code class="language-rust noplayground">pub trait HelloMacro {
|
||||
fn hello_macro();
|
||||
}</code></pre>
|
||||
<figcaption><a href="#listing-20-38">Listing 20-38</a>: A simple trait that we will use with the <code>derive</code> macro</figcaption>
|
||||
</figure>
|
||||
<p>We have a trait and its function. At this point, our crate user could implement
|
||||
the trait to achieve the desired functionality, as in Listing 20-39.</p>
|
||||
<figure class="listing" id="listing-20-39">
|
||||
<span class="file-name">Filename: src/main.rs</span>
|
||||
<pre><code class="language-rust ignore">use hello_macro::HelloMacro;
|
||||
|
||||
struct Pancakes;
|
||||
|
||||
impl HelloMacro for Pancakes {
|
||||
fn hello_macro() {
|
||||
println!("Hello, Macro! My name is Pancakes!");
|
||||
}
|
||||
}
|
||||
|
||||
fn main() {
|
||||
Pancakes::hello_macro();
|
||||
}</code></pre>
|
||||
<figcaption><a href="#listing-20-39">Listing 20-39</a>: How it would look if users wrote a manual implementation of the <code>HelloMacro</code> trait</figcaption>
|
||||
</figure>
|
||||
<p>However, they would need to write the implementation block for each type they
|
||||
wanted to use with <code>hello_macro</code>; we want to spare them from having to do this
|
||||
work.</p>
|
||||
<p>Additionally, we can’t yet provide the <code>hello_macro</code> function with default
|
||||
implementation that will print the name of the type the trait is implemented
|
||||
on: Rust doesn’t have reflection capabilities, so it can’t look up the type’s
|
||||
name at runtime. We need a macro to generate code at compile time.</p>
|
||||
<p>The next step is to define the procedural macro. At the time of this writing,
|
||||
procedural macros need to be in their own crate. Eventually, this restriction
|
||||
might be lifted. The convention for structuring crates and macro crates is as
|
||||
follows: For a crate named <code>foo</code>, a custom <code>derive</code> procedural macro crate is
|
||||
called <code>foo_derive</code>. Let’s start a new crate called <code>hello_macro_derive</code> inside
|
||||
our <code>hello_macro</code> project:</p>
|
||||
<pre><code class="language-console">$ cargo new hello_macro_derive --lib
|
||||
</code></pre>
|
||||
<p>Our two crates are tightly related, so we create the procedural macro crate
|
||||
within the directory of our <code>hello_macro</code> crate. If we change the trait
|
||||
definition in <code>hello_macro</code>, we’ll have to change the implementation of the
|
||||
procedural macro in <code>hello_macro_derive</code> as well. The two crates will need to
|
||||
be published separately, and programmers using these crates will need to add
|
||||
both as dependencies and bring them both into scope. We could instead have the
|
||||
<code>hello_macro</code> crate use <code>hello_macro_derive</code> as a dependency and re-export the
|
||||
procedural macro code. However, the way we’ve structured the project makes it
|
||||
possible for programmers to use <code>hello_macro</code> even if they don’t want the
|
||||
<code>derive</code> functionality.</p>
|
||||
<p>We need to declare the <code>hello_macro_derive</code> crate as a procedural macro crate.
|
||||
We’ll also need functionality from the <code>syn</code> and <code>quote</code> crates, as you’ll see
|
||||
in a moment, so we need to add them as dependencies. Add the following to the
|
||||
<em>Cargo.toml</em> file for <code>hello_macro_derive</code>:</p>
|
||||
<figure class="listing">
|
||||
<span class="file-name">Filename: hello_macro_derive/Cargo.toml</span>
|
||||
<pre><code class="language-toml">[lib]
|
||||
proc-macro = true
|
||||
|
||||
[dependencies]
|
||||
syn = "2.0"
|
||||
quote = "1.0"
|
||||
</code></pre>
|
||||
</figure>
|
||||
<p>To start defining the procedural macro, place the code in Listing 20-40 into
|
||||
your <em>src/lib.rs</em> file for the <code>hello_macro_derive</code> crate. Note that this code
|
||||
won’t compile until we add a definition for the <code>impl_hello_macro</code> function.</p>
|
||||
<figure class="listing" id="listing-20-40">
|
||||
<span class="file-name">Filename: hello_macro_derive/src/lib.rs</span>
|
||||
<pre><code class="language-rust ignore does_not_compile">use proc_macro::TokenStream;
|
||||
use quote::quote;
|
||||
|
||||
#[proc_macro_derive(HelloMacro)]
|
||||
pub fn hello_macro_derive(input: TokenStream) -> TokenStream {
|
||||
// Construct a representation of Rust code as a syntax tree
|
||||
// that we can manipulate.
|
||||
let ast = syn::parse(input).unwrap();
|
||||
|
||||
// Build the trait implementation.
|
||||
impl_hello_macro(&ast)
|
||||
}</code></pre>
|
||||
<figcaption><a href="#listing-20-40">Listing 20-40</a>: Code that most procedural macro crates will require in order to process Rust code</figcaption>
|
||||
</figure>
|
||||
<p>Notice that we’ve split the code into the <code>hello_macro_derive</code> function, which
|
||||
is responsible for parsing the <code>TokenStream</code>, and the <code>impl_hello_macro</code>
|
||||
function, which is responsible for transforming the syntax tree: This makes
|
||||
writing a procedural macro more convenient. The code in the outer function
|
||||
(<code>hello_macro_derive</code> in this case) will be the same for almost every
|
||||
procedural macro crate you see or create. The code you specify in the body of
|
||||
the inner function (<code>impl_hello_macro</code> in this case) will be different
|
||||
depending on your procedural macro’s purpose.</p>
|
||||
<p>We’ve introduced three new crates: <code>proc_macro</code>, <a href="https://crates.io/crates/syn"><code>syn</code></a><!-- ignore -->,
|
||||
and <a href="https://crates.io/crates/quote"><code>quote</code></a><!-- ignore -->. The <code>proc_macro</code> crate comes with Rust,
|
||||
so we didn’t need to add that to the dependencies in <em>Cargo.toml</em>. The
|
||||
<code>proc_macro</code> crate is the compiler’s API that allows us to read and manipulate
|
||||
Rust code from our code.</p>
|
||||
<p>The <code>syn</code> crate parses Rust code from a string into a data structure that we
|
||||
can perform operations on. The <code>quote</code> crate turns <code>syn</code> data structures back
|
||||
into Rust code. These crates make it much simpler to parse any sort of Rust
|
||||
code we might want to handle: Writing a full parser for Rust code is no simple
|
||||
task.</p>
|
||||
<p>The <code>hello_macro_derive</code> function will be called when a user of our library
|
||||
specifies <code>#[derive(HelloMacro)]</code> on a type. This is possible because we’ve
|
||||
annotated the <code>hello_macro_derive</code> function here with <code>proc_macro_derive</code> and
|
||||
specified the name <code>HelloMacro</code>, which matches our trait name; this is the
|
||||
convention most procedural macros follow.</p>
|
||||
<p>The <code>hello_macro_derive</code> function first converts the <code>input</code> from a
|
||||
<code>TokenStream</code> to a data structure that we can then interpret and perform
|
||||
operations on. This is where <code>syn</code> comes into play. The <code>parse</code> function in
|
||||
<code>syn</code> takes a <code>TokenStream</code> and returns a <code>DeriveInput</code> struct representing the
|
||||
parsed Rust code. Listing 20-41 shows the relevant parts of the <code>DeriveInput</code>
|
||||
struct we get from parsing the <code>struct Pancakes;</code> string.</p>
|
||||
<figure class="listing" id="listing-20-41">
|
||||
<pre><code class="language-rust ignore">DeriveInput {
|
||||
// --snip--
|
||||
|
||||
ident: Ident {
|
||||
ident: "Pancakes",
|
||||
span: #0 bytes(95..103)
|
||||
},
|
||||
data: Struct(
|
||||
DataStruct {
|
||||
struct_token: Struct,
|
||||
fields: Unit,
|
||||
semi_token: Some(
|
||||
Semi
|
||||
)
|
||||
}
|
||||
)
|
||||
}</code></pre>
|
||||
<figcaption><a href="#listing-20-41">Listing 20-41</a>: The <code>DeriveInput</code> instance we get when parsing the code that has the macro’s attribute in Listing 20-37</figcaption>
|
||||
</figure>
|
||||
<p>The fields of this struct show that the Rust code we’ve parsed is a unit struct
|
||||
with the <code>ident</code> (<em>identifier</em>, meaning the name) of <code>Pancakes</code>. There are more
|
||||
fields on this struct for describing all sorts of Rust code; check the <a href="https://docs.rs/syn/2.0/syn/struct.DeriveInput.html"><code>syn</code>
|
||||
documentation for <code>DeriveInput</code></a> for more information.</p>
|
||||
<p>Soon we’ll define the <code>impl_hello_macro</code> function, which is where we’ll build
|
||||
the new Rust code we want to include. But before we do, note that the output
|
||||
for our <code>derive</code> macro is also a <code>TokenStream</code>. The returned <code>TokenStream</code> is
|
||||
added to the code that our crate users write, so when they compile their crate,
|
||||
they’ll get the extra functionality that we provide in the modified
|
||||
<code>TokenStream</code>.</p>
|
||||
<p>You might have noticed that we’re calling <code>unwrap</code> to cause the
|
||||
<code>hello_macro_derive</code> function to panic if the call to the <code>syn::parse</code> function
|
||||
fails here. It’s necessary for our procedural macro to panic on errors because
|
||||
<code>proc_macro_derive</code> functions must return <code>TokenStream</code> rather than <code>Result</code> to
|
||||
conform to the procedural macro API. We’ve simplified this example by using
|
||||
<code>unwrap</code>; in production code, you should provide more specific error messages
|
||||
about what went wrong by using <code>panic!</code> or <code>expect</code>.</p>
|
||||
<p>Now that we have the code to turn the annotated Rust code from a <code>TokenStream</code>
|
||||
into a <code>DeriveInput</code> instance, let’s generate the code that implements the
|
||||
<code>HelloMacro</code> trait on the annotated type, as shown in Listing 20-42.</p>
|
||||
<figure class="listing" id="listing-20-42">
|
||||
<span class="file-name">Filename: hello_macro_derive/src/lib.rs</span>
|
||||
<pre><code class="language-rust ignore"><span class="boring">use proc_macro::TokenStream;
|
||||
</span><span class="boring">use quote::quote;
|
||||
</span><span class="boring">
|
||||
</span><span class="boring">#[proc_macro_derive(HelloMacro)]
|
||||
</span><span class="boring">pub fn hello_macro_derive(input: TokenStream) -> TokenStream {
|
||||
</span><span class="boring"> // Construct a representation of Rust code as a syntax tree
|
||||
</span><span class="boring"> // that we can manipulate
|
||||
</span><span class="boring"> let ast = syn::parse(input).unwrap();
|
||||
</span><span class="boring">
|
||||
</span><span class="boring"> // Build the trait implementation
|
||||
</span><span class="boring"> impl_hello_macro(&ast)
|
||||
</span><span class="boring">}
|
||||
</span><span class="boring">
|
||||
</span>fn impl_hello_macro(ast: &syn::DeriveInput) -> TokenStream {
|
||||
let name = &ast.ident;
|
||||
let generated = quote! {
|
||||
impl HelloMacro for #name {
|
||||
fn hello_macro() {
|
||||
println!("Hello, Macro! My name is {}!", stringify!(#name));
|
||||
}
|
||||
}
|
||||
};
|
||||
generated.into()
|
||||
}</code></pre>
|
||||
<figcaption><a href="#listing-20-42">Listing 20-42</a>: Implementing the <code>HelloMacro</code> trait using the parsed Rust code</figcaption>
|
||||
</figure>
|
||||
<p>We get an <code>Ident</code> struct instance containing the name (identifier) of the
|
||||
annotated type using <code>ast.ident</code>. The struct in Listing 20-41 shows that when
|
||||
we run the <code>impl_hello_macro</code> function on the code in Listing 20-37, the
|
||||
<code>ident</code> we get will have the <code>ident</code> field with a value of <code>"Pancakes"</code>. Thus,
|
||||
the <code>name</code> variable in Listing 20-42 will contain an <code>Ident</code> struct instance
|
||||
that, when printed, will be the string <code>"Pancakes"</code>, the name of the struct in
|
||||
Listing 20-37.</p>
|
||||
<p>The <code>quote!</code> macro lets us define the Rust code that we want to return. The
|
||||
compiler expects something different from the direct result of the <code>quote!</code>
|
||||
macro’s execution, so we need to convert it to a <code>TokenStream</code>. We do this by
|
||||
calling the <code>into</code> method, which consumes this intermediate representation and
|
||||
returns a value of the required <code>TokenStream</code> type.</p>
|
||||
<p>The <code>quote!</code> macro also provides some very cool templating mechanics: We can
|
||||
enter <code>#name</code>, and <code>quote!</code> will replace it with the value in the variable
|
||||
<code>name</code>. You can even do some repetition similar to the way regular macros work.
|
||||
Check out <a href="https://docs.rs/quote">the <code>quote</code> crate’s docs</a> for a thorough introduction.</p>
|
||||
<p>We want our procedural macro to generate an implementation of our <code>HelloMacro</code>
|
||||
trait for the type the user annotated, which we can get by using <code>#name</code>. The
|
||||
trait implementation has the one function <code>hello_macro</code>, whose body contains the
|
||||
functionality we want to provide: printing <code>Hello, Macro! My name is</code> and then
|
||||
the name of the annotated type.</p>
|
||||
<p>The <code>stringify!</code> macro used here is built into Rust. It takes a Rust
|
||||
expression, such as <code>1 + 2</code>, and at compile time turns the expression into a
|
||||
string literal, such as <code>"1 + 2"</code>. This is different from <code>format!</code> or
|
||||
<code>println!</code>, which are macros that evaluate the expression and then turn the
|
||||
result into a <code>String</code>. There is a possibility that the <code>#name</code> input might be
|
||||
an expression to print literally, so we use <code>stringify!</code>. Using <code>stringify!</code>
|
||||
also saves an allocation by converting <code>#name</code> to a string literal at compile
|
||||
time.</p>
|
||||
<p>At this point, <code>cargo build</code> should complete successfully in both <code>hello_macro</code>
|
||||
and <code>hello_macro_derive</code>. Let’s hook up these crates to the code in Listing
|
||||
20-37 to see the procedural macro in action! Create a new binary project in
|
||||
your <em>projects</em> directory using <code>cargo new pancakes</code>. We need to add
|
||||
<code>hello_macro</code> and <code>hello_macro_derive</code> as dependencies in the <code>pancakes</code>
|
||||
crate’s <em>Cargo.toml</em>. If you’re publishing your versions of <code>hello_macro</code> and
|
||||
<code>hello_macro_derive</code> to <a href="https://crates.io/">crates.io</a><!-- ignore -->, they
|
||||
would be regular dependencies; if not, you can specify them as <code>path</code>
|
||||
dependencies as follows:</p>
|
||||
<pre><code class="language-toml">[dependencies]
|
||||
hello_macro = { path = "../hello_macro" }
|
||||
hello_macro_derive = { path = "../hello_macro/hello_macro_derive" }
|
||||
</code></pre>
|
||||
<p>Put the code in Listing 20-37 into <em>src/main.rs</em>, and run <code>cargo run</code>: It
|
||||
should print <code>Hello, Macro! My name is Pancakes!</code>. The implementation of the
|
||||
<code>HelloMacro</code> trait from the procedural macro was included without the
|
||||
<code>pancakes</code> crate needing to implement it; the <code>#[derive(HelloMacro)]</code> added the
|
||||
trait implementation.</p>
|
||||
<p>Next, let’s explore how the other kinds of procedural macros differ from custom
|
||||
<code>derive</code> macros.</p>
|
||||
<h3 id="attribute-like-macros"><a class="header" href="#attribute-like-macros">Attribute-Like Macros</a></h3>
|
||||
<p>Attribute-like macros are similar to custom <code>derive</code> macros, but instead of
|
||||
generating code for the <code>derive</code> attribute, they allow you to create new
|
||||
attributes. They’re also more flexible: <code>derive</code> only works for structs and
|
||||
enums; attributes can be applied to other items as well, such as functions.
|
||||
Here’s an example of using an attribute-like macro. Say you have an attribute
|
||||
named <code>route</code> that annotates functions when using a web application framework:</p>
|
||||
<pre><code class="language-rust ignore">#[route(GET, "/")]
|
||||
fn index() {</code></pre>
|
||||
<p>This <code>#[route]</code> attribute would be defined by the framework as a procedural
|
||||
macro. The signature of the macro definition function would look like this:</p>
|
||||
<pre><code class="language-rust ignore">#[proc_macro_attribute]
|
||||
pub fn route(attr: TokenStream, item: TokenStream) -> TokenStream {</code></pre>
|
||||
<p>Here, we have two parameters of type <code>TokenStream</code>. The first is for the
|
||||
contents of the attribute: the <code>GET, "/"</code> part. The second is the body of the
|
||||
item the attribute is attached to: in this case, <code>fn index() {}</code> and the rest
|
||||
of the function’s body.</p>
|
||||
<p>Other than that, attribute-like macros work the same way as custom <code>derive</code>
|
||||
macros: You create a crate with the <code>proc-macro</code> crate type and implement a
|
||||
function that generates the code you want!</p>
|
||||
<h3 id="function-like-macros"><a class="header" href="#function-like-macros">Function-Like Macros</a></h3>
|
||||
<p>Function-like macros define macros that look like function calls. Similarly to
|
||||
<code>macro_rules!</code> macros, they’re more flexible than functions; for example, they
|
||||
can take an unknown number of arguments. However, <code>macro_rules!</code> macros can
|
||||
only be defined using the match-like syntax we discussed in the <a href="#declarative-macros-with-macro_rules-for-general-metaprogramming">“Declarative
|
||||
Macros for General Metaprogramming”</a><!-- ignore --> section earlier.
|
||||
Function-like macros take a <code>TokenStream</code> parameter, and their definition
|
||||
manipulates that <code>TokenStream</code> using Rust code as the other two types of
|
||||
procedural macros do. An example of a function-like macro is an <code>sql!</code> macro
|
||||
that might be called like so:</p>
|
||||
<pre><code class="language-rust ignore">let sql = sql!(SELECT * FROM posts WHERE id=1);</code></pre>
|
||||
<p>This macro would parse the SQL statement inside it and check that it’s
|
||||
syntactically correct, which is much more complex processing than a
|
||||
<code>macro_rules!</code> macro can do. The <code>sql!</code> macro would be defined like this:</p>
|
||||
<pre><code class="language-rust ignore">#[proc_macro]
|
||||
pub fn sql(input: TokenStream) -> TokenStream {</code></pre>
|
||||
<p>This definition is similar to the custom <code>derive</code> macro’s signature: We receive
|
||||
the tokens that are inside the parentheses and return the code we wanted to
|
||||
generate.</p>
|
||||
<h2 id="summary"><a class="header" href="#summary">Summary</a></h2>
|
||||
<p>Whew! Now you have some Rust features in your toolbox that you likely won’t use
|
||||
often, but you’ll know they’re available in very particular circumstances.
|
||||
We’ve introduced several complex topics so that when you encounter them in
|
||||
error message suggestions or in other people’s code, you’ll be able to
|
||||
recognize these concepts and syntax. Use this chapter as a reference to guide
|
||||
you to solutions.</p>
|
||||
<p>Next, we’ll put everything we’ve discussed throughout the book into practice
|
||||
and do one more project!</p>
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user