The virtue of unsynn

The Cost of Convenience

Rust's declarative macros work well for pattern-matched syntax, but they struggle with anything that doesn't fit a rigid template. A simple visibility modifier breaks them:

The fix is straightforward—until the next piece of syntax comes along. Procedural macros with syn solve this by parsing entire Rust syntax trees, letting us handle arbitrary function bodies, visibility modifiers, attributes, and everything else without writing brittle matching logic.

// With syn, parsing a full function is trivial
use proc_macro::TokenStream;
use quote::quote;
use syn::parse_macro_input;
#[proc_macro_attribute]
pub fn print_fn_name(_attr: TokenStream, item: TokenStream) -> TokenStream {
let input: syn::ItemFn = parse_macro_input!(item);
let fn_vis = &input.vis;
let fn_sig = &input.sig;
let fn_name = &input.sig.ident;
let fn_block = &input.block;
let expanded = quote! {
        #fn_vis #fn_sig {
println!("Function name: {}", stringify!(#fn_name));
            #fn_block
        }
};
TokenStream::from(expanded)
}

But that convenience has a price. Adding syn as a dependency means adding dozens of transitive dependencies, and every proc macro crate that depends on it must compile all of them. For a project using multiple proc macros, this adds up quickly.

Build Times: The Real Picture

The build time gap between declarative and procedural macros is significant. During a cold build, that syn-based proc macro pulls in its entire dependency tree, and with limited parallelism in CI environments, the wait is palpable:

On a local machine with full parallelism, an M4 Pro can chew through builds fast enough that the difference barely registers. But that's not the scenario most developers face. With -j1—a fair proxy for constrained CI environments—the build time jumps dramatically. And the gap grows even wider when you want optimized proc macros:

Critics offer two common refrains. First, that proc macros are inherently expensive and that's simply the way things are. Second, that only cold builds suffer, and warm builds make the difference irrelevant.

The first argument deserves scrutiny. It's entirely possible to write proc macros with zero dependencies—just raw token streams:

It works, and it's fast. The ergonomics, however, leave much to be desired. You lose structured parsing, type information, proper error messages, and all the conveniences that make proc macros pleasant to write.

The Middle Ground

What if there were something between hand-rolling token stream manipulation and pulling in the full syn machinery? A library that provides lightweight, composable parsers without requiring the entire Rust AST to be modeled in types?

This is where the core tension lies. syn models the entire Rust language—every expression, pattern, type, and statement. That's what makes it powerful but also what makes it heavy. The question is whether you need all of that, or whether a simpler approach to parsing—one built on lower-level operations—can give you the convenience you actually need at a fraction of the compile-time cost.

The unsynn approach

With unsynn, the parsing problem gets considerably simpler. The crate avoids the full Rust AST and instead works directly with the token stream, letting you define exactly what you need.

First, we bring in the crate and define the fn keyword we'll need:

keyword! is a declarative macro; the curious can inspect its expansion:

Next, we declare what we want to parse inside the unsynn! macro:

Breaking down the combinators used here:

• Many matches one or more of the contained pattern, similar to + in regular expressions.
• Cons sequences two things that follow each other.
• Except performs a lookahead to confirm a token does not match; it consumes nothing but rejects a match.
• KFn is our defined keyword — a bare fn, not a string literal. Custom keywords are allowed here too.
• TokenTree captures an entire token tree — for instance, a parenthesized expression counts as one.

The point is we're not parsing what we don't need. We skip tokens until we hit fn, grab an identifier, skip to the body, and take the body.

Within unsynn!, structs represent sequences of things (like Cons<...> but with named fields); enums represent alternatives. Option<T> works as well. Defining these as named structs lets us implement quote::ToTokens on them:

Yes, quote is still in use, sharing the proc_macro2 dependency — a necessary evil since the proc_macro API is currently unavailable to non-proc-macro crates. A tracking issue exists to address this, with a PR awaiting adoption at the time of writing. Until then, an abstraction layer is required to write unit tests.

This explains the conversions in our entry point:

We start by converting the input TokenStream from the built-in proc_macro form to the proc_macro2 variant, then parse it into FunctionDecl. There is no error recovery here — the parsing logic is intentionally simple — but for our test function, it suffices.

After parsing, we destructure the fields so quote! can interpolate them, preserving span information. This only works for types implementing quote::ToTokens, which is why we need three more implementations:

These largely forward to existing implementations — unsynn provides its own ToTokens trait that behaves essentially the same. For comparison, see quote::ToTokens and unsynn::ToTokens.

Compile-time costs

The natural question: what do compile times look like? unsynn does less work than syn, but it's more practical than dealing with the raw proc_macro API. Cold build times tell part of the story:

Unquestionably lighter than syn — but it's also doing fewer things. That's the point.

Warm builds matter more

One could argue cold build times don't matter if caching is set up properly, with cargo-binstall handling prebuilt dependencies. So let's look at warm builds.

To make the point, the body of main now repeats this block a hundred times:

This is literal AI slop, generated with GPT-4.1 at increasing nesting depths. The results:

The measurement procedure: touch main.rs, then rerun cargo build. As of May 2025, cargo's checksum-freshness option remains unstable, so changing the file's modification time triggers a rebuild. Dependencies themselves aren't rebuilt — we're not paying to rebuild syn — but we are waiting for syn to parse the entire function body from a token stream, after the Rust compiler has already tokenized it and built its own AST over that same stream.

On this benchmark, roughly 200 milliseconds is the cost of parsing and compiling all that. The declarative macro is essentially free; invoking an already-built proc macro runs on the order of 10 milliseconds. Parsing those ~11,000 lines of AI slop takes syn about 100 milliseconds.

This is the real reason to be cautious with syn. It's a fascinating, wonderful tool for writing proc macros, but it doesn't let you do less — it always parses the full Rust AST, even when your needs are far more modest. syn being large-ish is acceptable; alternatives will over time grow and carry their own one-time compilation cost.

But proc macro invocations are currently not cached, and it's unclear whether they will be. Any proc macro parsing and generating substantial amounts of code does so on every compilation where cargo suspects something changed — even when nothing did. That's why minimally-worked proc macros matter, keeping both cold and warm compile times from ballooning the way they do with syn and serde today.

Impact at scale

Micro-projects demonstrate the cost, but does syn actually slow down larger builds? In the dependency tree of beardist, an internal tool, syn appears eight separate times:

Removing syn from that tree would require replacing serialization, argument parsing, and dropping reqwest — which depends on syn through the url crate. That's enormous effort.

There's a trick, though: simulate making syn faster by running one build where every crate takes twice as long, then another where every crate except syn takes twice as long. Between those builds, a virtual speedup emerges — a technique borrowed from the coz causal profiler.

Absolute timings aren't meaningful here, but we gain a magic checkbox: "Make this crate build twice as fast," revealing what would happen under cargo's actual scheduler.

Some findings from this exercise:

• jiff, which accounts for a significant portion of the build time, is not on the critical path — speeding it up buys nothing on cold builds.
• Making tokio build twice as fast yields little difference.
• Even magically speeding up serde_derive has no measurable effect on this project.

Making syn twice as fast, however, compacts the entire build graph. Proc-macro dependencies like serde_derive and clap_derive shift left with their dependents, shaving a solid 10% off total build time.

Interestingly, the tooling to produce this graph compaction — this visualization of syn sitting on the critical path — was written only after the article was drafted, out of pure conviction.

Sometimes hubris pays off.

Reproducing the analysis

For patrons supporting at five euros per month or more, fargo is available in the extras section of the blog. This wrapper around cargo and rustc listens for artifact notifications, artificially delays them, and converts cargo's HTML timing files into JSON, ready for a Svelte 5 component that renders the visualizations shown above.

fargo runs fully offline, making it suitable for proprietary codebases — you can finally go to your boss and say, "I told you so." Author anecdotes aside, it's open source on GitHub.