Which model would you recommend? I’ve heard they can be a bit noisy
28.01.2026 08:13
👍 3
🔁 0
💬 0
📌 0
Which model would you recommend? I’ve heard they can be a bit noisy
The goal of the expansion is to eventually call back into the first proc macro, so it can keep its state in a static.
Yes. No idea how robust this solution is, but it makes for a cool demo.
With some sort of message passing, by having both macros recursively call each other github.com/alexkirsz/pr...
Bit me a couple of times bsky.app/profile/alex...
Context: I have a single macro call generating a ton of unrelated top-level items. I’d like to understand whether this can already be split up into multiple codegen units, or whether there’s a way to nudge the compiler towards doing it. @amanieu.bsky.social mentioned splitting into modules may help.
@noratrieb.dev Hey Nora, I had a question following your talk at EuroRust (great talk btw!). You mentioned the compiler is able to split up a single crate into codegen units. Could you describe the heuristics involved?
Thanks for your work!
Congrats Ruben! I'll watch the recording 😄
I would love something like that, but across our whole workspace.
needs more liquid glass
If you change that syntax to `#[facet(default(some_func()))]`, rustfmt will also be able to format within the attribute (and you still get RA go-to-def!)
IIRC it won't format the `=` form because it's not valid Rust syntax.
What about "miroir"?
Would love to start seeing better Supermaven integration! For some reason, the Zeta model does very poorly on our codebase, even on repetitive boilerplate code with dozens of examples.
fut1 is polled once, which is enough for it to request a lock on a mutex without actually getting it as it's already locked elsewhere. Once the other lock is dropped, fut2 requests a lock, but will never get it as fut1 is still alive, even if it isn't actively being polled.
Here's a playground example of the issue play.rust-lang.org?%E2%80%94=st...
However, a more surprising effect of this is that the future doesn't need to have been notified about the mutex being locked at all for it to hold the lock anyway. It just needs to have started .awaiting it and not have been dropped.
Fun deadlock of the day: Tokio mutexes are "fair", which means that locks/acquires will complete in the order they were called. A future doesn't need to be actively polled for it to hold the lock, which makes sense as locks need to be held across .await points.
When’s the next one?
You could pass it as a path that references the actual implementation function. Like serde(serialize_with).
Derive macro attribute?
#[derive(Foo)]
#[foo(bar = “bar”)]
struct S;
If you're using Bazel instead of Cargo, you could make a third crate that both crate 1 and crate 2 depend on, which contains a public type which is necessary to implement and/or name `SomeTrait`. Then make that crate only visible to crate 1 and crate 2.
I’m on macOS, running rust-analyzer on a large Bazel project.
Also, Zed sometimes stop being able to open and read new files. I've seen it report "too many files open" in the past, but now it seems to fail silently. Also reported this a while back. This happens around once a day on a large monorepo.
I’ve created a few already 😄
The one thing that keeps me at the edge of switching to VS Code and back is the quality of the Supermaven integration. Things like suggestions not refreshing, support for replacement suggestions, etc. I reverted to Copilot this week because it got to the point where it was slowing me down.
I feel the Zed integration is particularly bad and got worse recently. I recall it being leagues better on VS Code. But it might be the model itself has changed.
...rustc
Very nice
