1 Parser for Rust source code
2 ===========================
4 [<img alt="github" src="https://img.shields.io/badge/github-dtolnay/syn-8da0cb?style=for-the-badge&labelColor=555555&logo=github" height="20">](https://github.com/dtolnay/syn)
5 [<img alt="crates.io" src="https://img.shields.io/crates/v/syn.svg?style=for-the-badge&color=fc8d62&logo=rust" height="20">](https://crates.io/crates/syn)
6 [<img alt="docs.rs" src="https://img.shields.io/badge/docs.rs-syn-66c2a5?style=for-the-badge&labelColor=555555&logo=docs.rs" height="20">](https://docs.rs/syn)
7 [<img alt="build status" src="https://img.shields.io/github/actions/workflow/status/dtolnay/syn/ci.yml?branch=master&style=for-the-badge" height="20">](https://github.com/dtolnay/syn/actions?query=branch%3Amaster)
9 Syn is a parsing library for parsing a stream of Rust tokens into a syntax tree
12 Currently this library is geared toward use in Rust procedural macros, but
13 contains some APIs that may be useful more generally.
15 - **Data structures** — Syn provides a complete syntax tree that can represent
16 any valid Rust source code. The syntax tree is rooted at [`syn::File`] which
17 represents a full source file, but there are other entry points that may be
18 useful to procedural macros including [`syn::Item`], [`syn::Expr`] and
21 - **Derives** — Of particular interest to derive macros is [`syn::DeriveInput`]
22 which is any of the three legal input items to a derive macro. An example
23 below shows using this type in a library that can derive implementations of a
26 - **Parsing** — Parsing in Syn is built around [parser functions] with the
27 signature `fn(ParseStream) -> Result<T>`. Every syntax tree node defined by
28 Syn is individually parsable and may be used as a building block for custom
29 syntaxes, or you may dream up your own brand new syntax without involving any
30 of our syntax tree types.
32 - **Location information** — Every token parsed by Syn is associated with a
33 `Span` that tracks line and column information back to the source of that
34 token. These spans allow a procedural macro to display detailed error messages
35 pointing to all the right places in the user's code. There is an example of
38 - **Feature flags** — Functionality is aggressively feature gated so your
39 procedural macros enable only what they need, and do not pay in compile time
42 [`syn::File`]: https://docs.rs/syn/1.0/syn/struct.File.html
43 [`syn::Item`]: https://docs.rs/syn/1.0/syn/enum.Item.html
44 [`syn::Expr`]: https://docs.rs/syn/1.0/syn/enum.Expr.html
45 [`syn::Type`]: https://docs.rs/syn/1.0/syn/enum.Type.html
46 [`syn::DeriveInput`]: https://docs.rs/syn/1.0/syn/struct.DeriveInput.html
47 [parser functions]: https://docs.rs/syn/1.0/syn/parse/index.html
49 *Version requirement: Syn supports rustc 1.56 and up.*
51 [*Release notes*](https://github.com/dtolnay/syn/releases)
57 The best way to learn about procedural macros is by writing some. Consider
58 working through [this procedural macro workshop][workshop] to get familiar with
59 the different types of procedural macros. The workshop contains relevant links
60 into the Syn documentation as you work through each project.
62 [workshop]: https://github.com/dtolnay/proc-macro-workshop
66 ## Example of a derive macro
68 The canonical derive macro using Syn looks like this. We write an ordinary Rust
69 function tagged with a `proc_macro_derive` attribute and the name of the trait
70 we are deriving. Any time that derive appears in the user's code, the Rust
71 compiler passes their data structure as tokens into our macro. We get to execute
72 arbitrary Rust code to figure out what to do with those tokens, then hand some
73 tokens back to the compiler to compile into the user's crate.
75 [`TokenStream`]: https://doc.rust-lang.org/proc_macro/struct.TokenStream.html
87 use proc_macro::TokenStream;
89 use syn::{parse_macro_input, DeriveInput};
91 #[proc_macro_derive(MyMacro)]
92 pub fn my_macro(input: TokenStream) -> TokenStream {
93 // Parse the input tokens into a syntax tree
94 let input = parse_macro_input!(input as DeriveInput);
96 // Build the output, possibly using quasi-quotation
97 let expanded = quote! {
101 // Hand the output tokens back to the compiler
102 TokenStream::from(expanded)
106 The [`heapsize`] example directory shows a complete working implementation of a
107 derive macro. The example derives a `HeapSize` trait which computes an estimate
108 of the amount of heap memory owned by a value.
110 [`heapsize`]: examples/heapsize
114 /// Total number of bytes of heap memory owned by `self`.
115 fn heap_size_of_children(&self) -> usize;
119 The derive macro allows users to write `#[derive(HeapSize)]` on data structures
124 struct Demo<'a, T: ?Sized> {
134 ## Spans and error reporting
136 The token-based procedural macro API provides great control over where the
137 compiler's error messages are displayed in user code. Consider the error the
138 user sees if one of their field types does not implement `HeapSize`.
144 bad: std::thread::Thread,
148 By tracking span information all the way through the expansion of a procedural
149 macro as shown in the `heapsize` example, token-based macros in Syn are able to
150 trigger errors that directly pinpoint the source of the problem.
153 error[E0277]: the trait bound `std::thread::Thread: HeapSize` is not satisfied
156 7 | bad: std::thread::Thread,
157 | ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `HeapSize` is not implemented for `std::thread::Thread`
162 ## Parsing a custom syntax
164 The [`lazy-static`] example directory shows the implementation of a
165 `functionlike!(...)` procedural macro in which the input tokens are parsed using
168 [`lazy-static`]: examples/lazy-static
170 The example reimplements the popular `lazy_static` crate from crates.io as a
175 static ref USERNAME: Regex = Regex::new("^[a-z0-9_-]{3,16}$").unwrap();
179 The implementation shows how to trigger custom warnings and error messages on
183 warning: come on, pick a more creative name
184 --> src/main.rs:10:16
186 10 | static ref FOO: String = "lazy_static".to_owned();
194 When testing macros, we often care not just that the macro can be used
195 successfully but also that when the macro is provided with invalid input it
196 produces maximally helpful error messages. Consider using the [`trybuild`] crate
197 to write tests for errors that are emitted by your macro or errors detected by
198 the Rust compiler in the expanded code following misuse of the macro. Such tests
199 help avoid regressions from later refactors that mistakenly make an error no
200 longer trigger or be less helpful than it used to be.
202 [`trybuild`]: https://github.com/dtolnay/trybuild
208 When developing a procedural macro it can be helpful to look at what the
209 generated code looks like. Use `cargo rustc -- -Zunstable-options
210 --pretty=expanded` or the [`cargo expand`] subcommand.
212 [`cargo expand`]: https://github.com/dtolnay/cargo-expand
214 To show the expanded code for some crate that uses your procedural macro, run
215 `cargo expand` from that crate. To show the expanded code for one of your own
216 test cases, run `cargo expand --test the_test_case` where the last argument is
217 the name of the test file without the `.rs` extension.
219 This write-up by Brandon W Maister discusses debugging in more detail:
220 [Debugging Rust's new Custom Derive system][debugging].
222 [debugging]: https://quodlibetor.github.io/posts/debugging-rusts-new-custom-derive-system/
228 Syn puts a lot of functionality behind optional features in order to optimize
229 compile time for the most common use cases. The following features are
232 - **`derive`** *(enabled by default)* — Data structures for representing the
233 possible input to a derive macro, including structs and enums and types.
234 - **`full`** — Data structures for representing the syntax tree of all valid
235 Rust source code, including items and expressions.
236 - **`parsing`** *(enabled by default)* — Ability to parse input tokens into a
237 syntax tree node of a chosen type.
238 - **`printing`** *(enabled by default)* — Ability to print a syntax tree node as
239 tokens of Rust source code.
240 - **`visit`** — Trait for traversing a syntax tree.
241 - **`visit-mut`** — Trait for traversing and mutating in place a syntax tree.
242 - **`fold`** — Trait for transforming an owned syntax tree.
243 - **`clone-impls`** *(enabled by default)* — Clone impls for all syntax tree
245 - **`extra-traits`** — Debug, Eq, PartialEq, Hash impls for all syntax tree
247 - **`proc-macro`** *(enabled by default)* — Runtime dependency on the dynamic
248 library libproc_macro from rustc toolchain.
254 Syn operates on the token representation provided by the [proc-macro2] crate
255 from crates.io rather than using the compiler's built in proc-macro crate
256 directly. This enables code using Syn to execute outside of the context of a
257 procedural macro, such as in unit tests or build.rs, and we avoid needing
258 incompatible ecosystems for proc macros vs non-macro use cases.
260 In general all of your code should be written against proc-macro2 rather than
261 proc-macro. The one exception is in the signatures of procedural macro entry
262 points, which are required by the language to use `proc_macro::TokenStream`.
264 The proc-macro2 crate will automatically detect and use the compiler's data
265 structures when a procedural macro is active.
267 [proc-macro2]: https://docs.rs/proc-macro2/1.0/proc_macro2/
274 Licensed under either of <a href="LICENSE-APACHE">Apache License, Version
275 2.0</a> or <a href="LICENSE-MIT">MIT license</a> at your option.
281 Unless you explicitly state otherwise, any contribution intentionally submitted
282 for inclusion in this crate by you, as defined in the Apache-2.0 license, shall
283 be dual licensed as above, without any additional terms or conditions.