gpt-macro asks ChatGPT to write the function body your compiler is about to type-check

Expansion makes an HTTP call and then hands the reply to rustc

The mechanism is short enough to state exactly. A prompt string literal and a stub of target code sit inside the macro invocation. When the compiler expands the macro, the crate parses both, asks ChatGPT to fill in the code, extracts code from the response, replaces the target with it, and returns. Only then does the Rust compiler continue, type checking whatever came back. Nothing sits between the model and the compiler: there is no intermediate validation step, no schema, no allowlist of generated constructs. The dependency list confirms the shape of the work, since the crate pulls in an async OpenAI client with the chat-completion feature and Tokio with the multi-threaded runtime enabled, which means the expansion path stands up its own runtime inside the compiler process and blocks on the network. For a build, that converts every compile into a potential billable request and adds the latency of a round trip to the OpenAI API.

auto_impl takes a prompt literal, then a token stream

The invocation has two parts, and the documentation is explicit about their types: a $STR_LIT, which is a prompt string literal, and a $TOKEN_STREAM, which is the target code. That signature is what lets the macro read the function you have not finished writing:

auto_impl! {
    $STR_LIT
    $TOKEN_STREAM
}

The worked example is fizzbuzz, and it is written so the crate cannot be bypassed. The body of the function is left empty, so an ordinary build fails with an unimplemented function, and the test underneath it asserts the contract the prompt describes: fizzbuzz(3) is fizz, fizzbuzz(5) is buzz, fizzbuzz(15) is fizzbuzz, and fizzbuzz(1) is the string 1, which pins the fall-through case as a numeric string rather than a panic or an error type. The prompt text is the specification, and the assertions are the part you wrote. Without the macro the crate does not compile, which is the intended demonstration and also the reason this pattern cannot be adopted casually in code you need to build offline.

The compiler is the only reviewer of generated Rust

The README shows what a reply looks like, an if and else chain that returns String::from for the three cases and falls back to n.to_string(), followed by the test block that came back with it. That output is spliced in as written. So the safety story is entirely delegated to rustc: type errors, borrow errors and missing imports are caught, while anything that compiles is accepted, including logic that satisfies the assertions without being correct. Three operational gaps come with that. There is no documented behaviour for a response that does not parse as Rust, so a truncated or fenced reply becomes a compiler error that looks like a mistake in your own code. There is no feature flag to skip the call, since the features table is empty and the default is an empty list. And there is no cache, no retry and no offline fixture, so an identical build issues an identical request. None of that is a reason to reject the idea, but all of it belongs in a decision to put it in a build.

#[auto_test] takes its test names as arguments

The second implemented macro is an attribute rather than a function-like invocation, and its argument list is the test names:

use gpt_macro::auto_test;

#[auto_test(test_valid, test_div_by_zero)]
fn div_u32(a: u32, b: u32) -> u32 {
    if b == 0 {
        panic!("attempt to divide by zero");
    }
    a / b
}

Here the function is complete and the attribute is asked to produce two tests, one named test_valid and one named test_div_by_zero, with the divide-by-zero panic in the body as the obvious edge case for the second. What is missing is as informative as what is there. For auto_impl the README includes a sample response so you can see what the macro produced, and for auto_test there is no equivalent output block, no description of what assertions get written, and no statement about whether the generated tests are exhaustive, whether they are run at build time or left for cargo test, or what happens when the model returns tests that do not compile. Two macros, one with a documented output contract and one without.

Cargo.toml says 0.1.0 and there is no release behind it

The manifest is the whole publishing story. The crate is named gpt-macro, the version is 0.1.0, the edition is 2021, and the library target sets proc-macro to true, which is what makes the crate a procedural macro rather than a normal dependency. There are no GitHub releases, so the tag history offers nothing to pin against, and the last commit to the repository was 14 September 2026, under three weeks before this review, so the crate is being worked on without a versioned trail. The manifest also names a test target explicitly, a [[test]] entry called tests pointing at tests/tests.rs, which is a small sign of how the project expects itself to be checked. Licensing is MIT, stated in the README and backed by a LICENSE file at the root. For a crate whose output is model-generated, the version number is doing more work than usual, because 0.1.0 tells you nothing about whether the expansion format has changed since you last built.

The dependency set explains the design choices

Five runtime dependencies and one dev dependency describe the implementation without opening a single source file. syn is requested with the full, extra-traits and parsing features, which is what a macro needs to walk an arbitrary token stream rather than a narrow grammar. proc-macro2 is taken with its nightly feature, quote supplies the token-level code generation, async-openai at 0.42.0 with chat-completion is the model call, and tokio with rt-multi-thread is the runtime that call runs on. The dev dependency is trybuild with the diff feature, which is the standard harness for proc macros because it captures compiler output and diffs it, so a change in the generated code shows up as a test failure rather than as a silent difference. The repository tree matches that small surface: .github/, .gitignore, Cargo.toml, LICENSE, README.md, src/ and tests/, with no build script, no examples directory and no benchmarks. Nothing here tries to be a framework, and nothing is hidden.

The happy path is documented, the rest is not

What the README does cover is precise and short. It states the environment requirement plainly, get a ChatGPT API key and set it in OPENAI_API_KEY before you run, which is the entire setup section. It names the two implemented macros, gives the syntax, gives one complete example per macro, and states the MIT licence. What is missing is the list a careful adopter needs. There is no line telling you how to add the crate to a project, only the key. There is no statement of which model the request names or whether the model is configurable, so the model behind your build is whatever the crate was last written against. There is no mention of what a build costs, no note that the API key is read from the environment on every expansion, and no guidance on keeping generated code out of version control or reviewing it before it lands. The README also does not describe what happens when the request fails, is rate limited or returns prose instead of code, and for a build-time dependency those are the questions that decide whether it belongs in your tree.

Editorial conclusion

gpt-macro is worth reading as a demonstration of what a procedural macro can reach, and it is a poor dependency for a build you have to reproduce. Adopt it in a scratch crate, with a spending limit on the key, and never on a release pipeline where a network failure or a rate limit should not stop a compile. Before you try it, know that the generated code is checked only by the compiler, that every expansion is another billable request, and that the crate is version 0.1.0 with no published release behind it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. retrage/gpt-macro on GitHub