Rust Procedural Macro Developer Guide

What this prompt does

This prompt asks the AI to build a Rust procedural macro for [macro_purpose], set up as a separate proc-macro crate with syn, quote, and proc-macro2. It implements a derive macro that generates [derive_output] for annotated structs, parses struct fields with proper error handling for unsupported types, and emits code via the quote! macro with hygiene in mind. An attribute-macro variant accepting [attribute_params] is included, along with compile-time error reporting that uses span information for helpful messages.

The structure works because proc macros are sharp tools where small mistakes produce cryptic compile errors, so the prompt insists on the safety scaffolding from the start. It demands edge-case coverage for generics, lifetimes, enums, and tuple structs; a testing strategy using trybuild for compile-fail tests plus standard tests for generated code; and cargo expand for debugging. By naming [derive_output] and [attribute_params] precisely, you get a macro that generates exactly the shape you want instead of a generic stub.

When to use it

• Boilerplate is dragging down a Rust codebase and a derive macro can generate it safely — builders, serialization glue, conversions.
• You want an attribute macro that takes parameters like [attribute_params] to customize generation per struct.
• You need compile-time error messages with good spans so users of your macro get actionable feedback.
• You are handling tricky inputs — generics, lifetimes, enums, tuple structs — and want them covered, not ignored.
• You want a proper testing setup with trybuild compile-fail cases, not just happy-path checks.
• You are new to syn and quote and want a correct crate structure to learn from.

Example output

Expect a complete two-crate structure: the proc-macro crate with its Cargo.toml (syn, quote, proc-macro2) and the macro implementation, plus a usage example crate that consumes it. You get the derive and attribute macro code, trybuild compile-fail tests, standard tests for the generated output, and documentation showing an input struct alongside the generated result.

Pro tips

• Make [macro_purpose] specific — "Builder pattern for structs" yields far better parsing logic than "reduce boilerplate".
• Describe [derive_output] in detail, including method names and validation behavior, so the generated build() logic matches your intent.
• For [attribute_params], give the exact attribute syntax you want (defaults, required, rename); the parser is generated directly from it.
• Always run cargo expand on the result to inspect generated code — macros that compile can still emit subtly wrong tokens.
• Lean on trybuild compile-fail tests for the error paths; that is where macro quality lives, and the model often under-tests them.
• If generics or lifetimes break the generated code, feed the failing struct back and ask the model to handle that specific case.