gpt-macro: a Rust proc macro that asks ChatGPT to finish your code at compile time

What gpt-macro is for, and why compile-time generation is an odd place for an API call

gpt-macro targets Rust developers who want to write the shape of a function and let a model fill in the body. The README frames the motivation through its fizzbuzz example: the function signature and the tests are written by hand, the body is empty, and the build fails until the macro supplies an implementation. That is a narrower goal than a general code assistant. You are not chatting in an editor; you are embedding a prompt in the source and letting the compiler drive the call.

The intended audience is small. This is a proc macro crate at version 0.1.0 with two macros, no releases retrieved, and a repository that is mostly Cargo.toml, src/, tests/, and a README. Anyone evaluating it should treat it as a demonstration of a mechanism rather than a tool with a support story. The interesting question it poses is not whether a model can write fizzbuzz, but whether code generation belongs anywhere near the build graph. The README does not address that question, which is itself informative.

How the macro expansion works: prompt in, tokens out, compiler continues

The mechanism visible in the README is straightforward. `auto_impl!{}` takes two arguments: a string literal prompt and a token stream of target code. According to the README, the macro "parses given prompt and target code, and asks ChatGPT to fill the code when expanding the macro. It replaces the target with code extracted from ChatGPT response. Then Rust compiler continues compiling the code."

So the data flow is: your source contains an incomplete item, the proc macro runs during expansion, it issues a chat completion request through the async-openai dependency, it extracts code from the response text, and it emits that code as the macro's output tokens. The compiler never sees the incomplete version as an error because the macro replaces it before type checking.

The Cargo.toml confirms the machinery: proc-macro2 with the nightly feature, syn 3.0 with full parsing, quote 1.0 for token emission, async-openai 0.42.0 with the chat-completion feature, and tokio with a multi-thread runtime. A synchronous proc macro blocking on an async HTTP client is a design choice the README does not discuss, and it is the part I would question most. Proc macros run inside rustc; making one wait on a remote service couples build latency to network latency.

Installing gpt-macro and running the fizzbuzz example

The README gives one prerequisite: get a ChatGPT API key and set it as the environment variable `OPENAI_API_KEY` before running. There is no published install procedure beyond adding the crate as a dependency, and no version is suggested for that dependency, so the safest reading is that you add it the way you add any path or git dependency.

[dependencies]
gpt-macro = { path = "../gpt-macro" }

With the key exported, the README's example looks like this. The function body is deliberately empty, and the tests are part of the same token stream so the model sees what it must satisfy.

use gpt_macro::auto_impl;

auto_impl! {
    "Return fizz if the number is divisible by 3, buzz if the number is divisible by 5, and fizzbuzz if the number is divisible by both 3 and 5."
    fn fizzbuzz(n: u32) -> String {
    }

    #[test]
    fn test_fizzbuzz() {
        assert_eq!(fizzbuzz(3), "fizz");
        assert_eq!(fizzbuzz(5), "buzz");
        assert_eq!(fizzbuzz(15), "fizzbuzz");
        assert_eq!(fizzbuzz(1), "1");
    }
}

What you should see is a successful build, followed by the generated implementation in the macro output. The README shows a response example using `if n % 3 == 0 && n % 5 == 0` and `n.to_string()` for the fallback case, but it presents that as an example of what ChatGPT returned, not as a guaranteed result. That distinction matters: the README does not promise the same code twice.

The second macro, `#[auto_test(...)]`, is documented only by example. You annotate a function with a list of test names, and the macro generates those tests.

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
}

The README does not say what prompt is sent for `auto_test`, what the generated tests assert, or how failures are reported. You would have to read src/ to know.

The build now depends on a network service, and nothing in the README says what happens when it is down

This is the limitation that decides whether gpt-macro is usable for you. A proc macro that calls a remote API turns `cargo build` into an operation with external dependencies: a valid API key, a working network path to the API, a non-error response, and a response whose text can be parsed back into valid Rust tokens. The README documents the first of those and nothing about the rest.

There is no mention of caching generated output, no retry policy, no timeout, no offline mode, and no statement about what the macro emits when the API call fails. A reasonable guess is a compile error, but the README does not say, and that is exactly the kind of detail you need before putting this in a build that runs in CI. Incremental compilation may spare you repeated calls during local iteration, but a clean build has no such protection, and the README does not describe any persistence layer.

There is a second, quieter failure mode: non-determinism. If the model returns slightly different code on two runs, the emitted tokens differ, and the compiler treats that as a source change. Builds stop being reproducible. For a test crate that is an annoyance. For a published library it is disqualifying, because your users cannot reproduce your artifact.

gpt-macro compared with build.rs code generation and checked-in generated code

The conventional Rust alternative is a build script. A build.rs runs before compilation, writes generated Rust into OUT_DIR, and your crate includes it with `include!` or `include_str!`. The difference is not cosmetic. A build script is a program you control: it can call a template engine, a parser generator, or even an HTTP API, and it can cache the result to disk so subsequent builds are offline and deterministic. gpt-macro puts the call inside macro expansion instead, which means the generated code is not a file you can inspect, diff, or commit. There is no artifact to review before it enters your binary.

The other alternative is generating the code once, by hand or with a model, and committing it. That loses the novelty of compile-time generation and keeps everything that matters: reviewability, reproducibility, and builds that work on a plane. The honest comparison is that gpt-macro trades all three for convenience, and the README does not argue that the trade is worth it. A build.rs with a cached response would give you most of the mechanism with none of the build fragility.

Maintenance, dependencies and the MIT licence

The crate is MIT licensed, which is permissive: you can use, modify, and redistribute it, including in closed-source work, provided the licence text travels with it. That is the whole of the licence implication here, and it is not legal advice. Note that the MIT licence covers gpt-macro's source, not the OpenAI API terms or the model output, which the README does not discuss.

The last push to the repository was on 2026-09-14, and the repository is not archived, so it is current rather than dormant. Version 0.1.0 and the absence of retrieved releases tell you the API surface is not stabilized. The dependency list is where upgrade cost lives: syn 3.0, proc-macro2 1.0 with the nightly feature, quote 1.0, async-openai 0.42.0, and tokio 1.0. syn and proc-macro2 move in lockstep with compiler changes, and async-openai tracks an API that changes on its own schedule, so a future Rust release or OpenAI API revision can break the build without any change on your side. There is no changelog in the repository listing to tell you when that happens.

Editorial conclusion

Use gpt-macro if you want to see what compile-time LLM code generation feels like in Rust, or if you are prototyping throwaway code where a build that depends on a network call is acceptable. Do not use it for a library or binary that other people must build: the README does not document caching, retries, or determinism, so every clean build can produce different code and every offline build can fail. Before adopting it, check two things yourself: whether the crate compiles against the pinned syn 3.0 and async-openai 0.42.0, and what the macro does when OPENAI_API_KEY is unset or the API returns an error. The README documents neither.

Frequently asked questions

Official sources

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