The Arithmetic That Ran Before the Program

Our first macro can preserve this new piece of code as text:

code_string!(add(2, multiply(3, 4)))

This time we want an integer evaluator. Its language will be deliberately small:

integer literal
add(expression, expression)
multiply(expression, expression)

Every accepted input must become one i64 literal. eval_integer! does not promise to evaluate an arbitrary Rust expression.

println("{}", eval_integer!(add(2, multiply(3, 4))));

Can it expand into

2 + (3 * 4)

?

Yes. In the macro logic, you are not just creating code; you must also complete the arithmetic. To do that, we need some way to convert the Rust code into actual Rust values. We begin by designing a type that can hold these expressions. In compiler theory, this is usually called an abstract syntax tree.

enum IntegerExpr {
    Literal { value: i64 },
    Call(IntegerCall),
}

struct IntegerCall {
    function: String,
    arguments: Vec<IntegerExpr>,
}

Very close, but there is an important distinction between an AST type and an ordinary data type. An AST type must be defined either as an atomic AST type, such as the number 2, or as a struct or enum whose fields are themselves AST types.

It is LitInt. You have already seen the AST type for a string: LitStr. Revise your definition.

enum IntegerExpr {
    Literal { value: LitInt },
    Call(IntegerCall),
}

struct IntegerCall {
    function: LitStr,
    arguments: Vec<IntegerExpr>,
}

Ask Syn to produce the type named on the left:

let expression: IntegerExpr = syn::parse2(input)?;

the trait `Parse` is not implemented for `IntegerExpr`

Not for these regular shapes. We use syn_derive, a helper crate whose procedural macros generate the mappings from our type definitions. Our project usually requests both directions:

#[derive(syn_derive::Parse, syn_derive::ToTokens)]

Parse maps tokens into our value. ToTokens lets a later compiler stage put that value back into code.

Exactly. syn_derive::Parse runs when this macro crate is compiled and generates ordinary Rust code. Later, eval_integer! calls that generated code when it receives tokens from its caller.

It cannot infer that choice. We mark the first alternative with a rule:

enum IntegerExpr {
    #[parse(peek = LitInt)]
    Literal { value: LitInt },
    Call(IntegerCall),
}

#[parse(peek = LitInt)] asks whether the next token has the LitInt shape without consuming it. If it does, select Literal. If it does not, continue to Call.

input 2          -> peek sees LitInt -> choose Literal -> value consumes 2
input add(...)   -> next token is not LitInt -> continue to Call

Exactly. Call has no peek annotation because it is the final fallback. Its fields must still match the remaining input. For example, input beginning with + reaches Call but then fails because its first field expects an identifier.

This one-token distinction is enough because we deliberately designed the two forms to begin differently. If two alternatives began the same way, we would need a different or more detailed selection rule. That general theory is outside this tutorial.

No. LitStr represents a quoted Rust string literal. A bare name such as add is an identifier, represented by Syn's Ident:

function: Ident,

After that field consumes add, the remaining input is (2, 3). Does Vec<IntegerExpr> say where that list begins or which token separates its elements?

Then evolve that field into a syntax-aware, comma-separated list:

#[syn(parenthesized)]
paren_token: token::Paren,
#[syn(in = paren_token)]
#[parse(Punctuated::parse_terminated)]
arguments: Punctuated<IntegerExpr, Token![,]>,

parenthesized                         recognize (...) and keep its delimiter
in = paren_token                     read the next field from inside (...)
Punctuated<IntegerExpr, Token![,]>   keep expressions separated by commas
parse_terminated                     use Syn's existing list mapping

Unlike Vec, Punctuated retains the separators so ToTokens can write the same call shape back into code.

add       -> function: Ident
(2, 3)    -> paren_token opens the nested input
2, 3      -> arguments: Punctuated<IntegerExpr, Token![,]>

Both IntegerExpr and IntegerCall now derive the two mappings. Try the line that failed before:

let expression: IntegerExpr = syn::parse2(input)?;

Now the input is an IntegerExpr. How would you define its value from the two enum alternatives?

Literal(n)                 -> n
Call add(left, right)      -> evaluate(left) + evaluate(right)
Call multiply(left, right) -> evaluate(left) * evaluate(right)

Write only that enum dispatch first.

Yes. base10_parse() is Syn's conversion from an integer-literal syntax value to a Rust integer. For calls, the helper renders the stored Ident as text, pairs it with arguments.len(), and matches the supported name-and-arity combination. Which two combinations should have meaning?

We now have the token-to-IntegerExpr mapping, the evaluator, and Quote from R.1. How should expand_expression connect them?

let expression: IntegerExpr = syn::parse2(input)?;
let value = evaluate(&expression)?;
Ok(quote! { #value })

With the notes folder open in VS Code, expand eval_integer!(add(2, multiply(3, 4))) using rust-analyzer: Expand macro recursively at caret.

Now run the caller:

cargo run --manifest-path examples/rust-02-compile-time/Cargo.toml --package compile-time-demo

14