# dtolnay/case-studies: the Rust language patterns that advanced macro libraries emit > A set of written case studies by dtolnay on the Rust code patterns that sophisticated macro libraries generate. No crate to install: the repository holds seven analyses of emitted code, not of macro mechanics. **dtolnay/case-studies** — Analysis of various tricky Rust code - Repository: https://github.com/dtolnay/case-studies - Stars: 2,048 · Forks: 52 - Language: Rust - License: Apache-2.0 - Published: 2026-10-11 · Updated: 2026-10-11 · Language: en - Canonical page: https://hysenlabs.com/projects/dtolnay-case-studies ## The core argument: 90% of macro skill is Rust skill, not macro knowledge The README opens with a thesis that shapes every case study in the repository. The difference between a competent Rust macro developer and an expert one, it argues, has nothing to do with how well they understand macros. 90% of what lets someone push the limits of a macro library comes from mastery of the Rust language outside of macros, combined with the creativity to put ordinary language features together in ways that would not appear in handwritten code. Procedural macros, the README observes, always just parse some input in a boring way, crawl some syntax trees in a boring way, and paste together output code in a boring way. The interesting decision is what that output should look like, and that is a Rust problem, not a macro problem. This repository is the written record of that argument. ## Structure of each case study: constraints first, code second, macro last Each case study follows a consistent structure. First, it explains a set of constraints that generated code will need to satisfy, giving just enough context about the relevant macro to make those constraints concrete. Second, it works through the generated code itself, showing how ordinary Rust language features can be combined to meet the constraints in ways that might not come to mind directly. Third, and last, it ties the result back to the macro context, noting that writing the macro to produce the identified code would be the easy part. A reader who skips to the macro sections misses the point. The ingenuity in each case study lives entirely in the generated code section, and the macro context is there only to explain why the constraints exist. The README's phrase for what each case study looks for is a clever combination of Rust language features unrelated to macros. ## 7 published case studies and the Rust mechanisms each one names The repository lists 7 published case studies. Function epilogue addresses the borrow checker, no_std environments, closures and lifetime elision. Multiple of 8 const assertion covers compiler diagnostics, name resolution, const evaluation and traits. Unit struct with type parameters spans namespaces, glob imports, layout optimization, autotraits and documentation. Read-only fields of a mutable struct involves deref coercion, the borrow checker, repr attributes, unsafe code and documentation. Consecutive integer match patterns covers macro_rules and const. User-defined callable types draws on deref coercion, closures, trait objects, repr and unsafe code. Autoref-based stable specialization deals with traits and method resolution. Reading the topic tags together shows which Rust mechanisms recur across multiple cases. Deref coercion appears in both callable types and read-only fields. Repr appears in both read-only fields and callable types. The borrow checker appears in both function epilogue and read-only fields. Each case study applies a familiar mechanism under a different set of constraints, so the overlap is purposeful: seeing the same tool solve a second problem is the point. ## The Cargo.toml workspace: 8 members across 6 case study demos The Cargo.toml at the repository root defines a workspace with resolver 2 and 8 members: bitfield-assertion/demo, bitfield-assertion/demo/bitfield, bitfield-assertion/demo/impl, callable-types/demo, function-epilogue/demo, integer-match/demo, readonly-fields/demo and unit-type-parameters/demo. That count is worth pausing on. Seven case studies appear in the README, but only 6 of them have workspace members, and 1 of those 6 contributes 3 members rather than one. The bitfield-assertion case study splits into a top-level demo package, a bitfield subcrate and an impl subcrate. This 3-crate layout mirrors the realistic structure of a macro library, where the proc-macro implementation crate and the user-facing type typically live in separate packages. The other 5 demos that appear in the workspace each contribute a single member. ## autoref-specialization has a folder and a README entry but no workspace member Among the seven case studies listed in the README, autoref-based stable specialization is an anomaly worth checking before relying on the workspace. Its folder, autoref-specialization/, appears in the top-level repository file listing alongside the six other case study directories. The README entry exists, links to a full analysis and names traits and method resolution as its topics. However, no autoref-specialization entry appears anywhere in the Cargo.toml workspace members list. Running cargo build from the repository root compiles the eight workspace members for the six case studies that do appear in the workspace, and nothing from autoref-specialization/. The written analysis in that subdirectory is readable directly, but the workspace tooling does not build anything from it. This gap is not mentioned in the README. ## Accessing the material: GitHub reading vs. cloning the workspace The repository contains no published crate and nothing to add as a dependency. Reading the written analyses on GitHub requires no local setup. Cloning the repository and running cargo build compiles the eight workspace members for the six case studies with workspace entries. That build step is optional: none of the written analyses depend on running the code to follow the argument. The project is licensed under either Apache 2.0 or MIT, at the user's option, and contributions are dual-licensed on those same terms. The last push was on 2026-07-18, and the repository carries no GitHub releases and is not archived. The README links to dtolnay/proc-macro-workshop as the place to learn procedural macro basics. These case studies assume that foundation and go further: each one starts from a constraint that a macro imposes and works out how the generated code can satisfy it using mechanisms that have nothing to do with how macros are written. ## Who will not get value from this repository Several audiences will find the case studies unrewarding. Someone who has not yet written production Rust will not be able to follow them; they assume comfort with borrow checking rules, trait resolution, repr attributes, lifetime elision and unsafe code without stopping to explain those concepts. Someone who only wants to use serde, syn or a similar macro-based crate faces a different question, one about the public API rather than the implementation patterns behind it. A developer looking for a step-by-step tutorial will not find one either: each case study presents a finished analysis, not a guided exercise. The README links to dtolnay/proc-macro-workshop for that kind of structured learning. What this repository offers is an explanation of why certain generated patterns work, and that explanation has value only once the underlying Rust concepts are already familiar. ## Conclusion This repository is for Rust developers who already write procedural macros and want to understand the generated code patterns that make libraries like bitfield possible. If you are new to Rust or only want to use macro-based crates rather than build them, the case studies will not be useful. The seven written analyses are readable on GitHub without any local setup. Before working through the repository, note that the autoref-specialization directory has no workspace entry in Cargo.toml, so cargo build from the root will not compile anything from it. ## FAQ ### What is the dtolnay/case-studies repository? A collection of written analyses by dtolnay of tricky Rust code patterns that arise from advanced macro library development. The focus in each case study is the code that macros generate, not the macro implementation itself. ### Do I need to know how to write Rust macros before reading these case studies? The README argues that macro-specific knowledge is a small part of the skill set; 90% of what matters is mastery of Rust outside of macros. The case studies focus on generated Rust code and the language features that make it work, with the macro context given only as background for the constraints. ### Is dtolnay/case-studies a Rust library I can add to my project? No. The repository contains no published crate and is not on crates.io. It holds written analyses and demo code in a Cargo workspace. Reading the Markdown files on GitHub requires no local setup. ### Can I compile and run the code examples in dtolnay/case-studies? Six of the seven case studies have demo crates in the Cargo workspace. Cloning the repository and running cargo build from the root compiles those eight workspace members. The autoref-specialization case study has a folder and a written analysis but no workspace entry in Cargo.toml, so the workspace does not build anything from it. ### What Rust topics do the dtolnay case studies cover? The seven case studies cover borrow checking, no_std, closures, lifetime elision, const evaluation, name resolution, traits, namespaces, glob imports, layout optimization, autotraits, deref coercion, repr, unsafe code, macro_rules and method resolution. ## Sources - [dtolnay/case-studies on GitHub](https://github.com/dtolnay/case-studies) - [Issues](https://github.com/dtolnay/case-studies/issues) - [License: Apache-2.0](https://github.com/dtolnay/case-studies/blob/master/LICENSE) - [README](https://github.com/dtolnay/case-studies/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dtolnay-case-studies