(I didn’t raise it originally because, having done other compiler work, I’m very sympathetic to the notion that there’s no perfect default or heuristic Rust can pick here :-))
Very true. A single report of “the heuristics are bad here” may not be very actionable. But it’s still valuable to have a place to collect them; if we get multiple such reports that may indicate a need to rebalance things a little.
score 1 · canonical
cargo also supports custom registries so GNOME could totally host their own that only contains stuff they trust.
score 2 · canonical
I suspect part of the reason is that many debug impls never get called, and by adding #[inline] we avoid ever codegen’ing them.
score 1 · canonical
This seems worth a bugreport in the rust-lang/rust repo. We’ve changed the #[inline] on Debug in the past and we can change it again. It’s just hard to pick a good trade-off between code size, compile time, and run time.
score 1 · canonical
Yeah it’s pretty sad… we were so close to stabilizing it, but then it turned out that some people had different ideas of the exact semantics of this intrinsic in terms of soundness reasoning. It took a lot of discussion for us to even figure out what the differences were. We did in the end all manage to agree on what the two options are, but then the inertia was gone and we didn’t manage to reach a consensus on which of the two options to pick, or how to name them if we decide to offer both options. So it remains unstable. :(
The disagreement boils down to the question of whether this code is sound:
pub fn my_fun() {
breakpoint();
unsafe { std::hint::unreachable_unchecked() };
}
We all agreed on what would happen if this is executed in a debugger, execution halts at the breakpoint, and the user says “continue” – the result is UB, i.e., something went wrong. But we disagreed on whose fault this is – is the function wrong for causing UB after breakpoint returns, or is the user interacting with the debugger wrong to ask the program to continue after this breakpoint?
score 2 · canonical
Does this page load for others? I get errors in every browser. Firefox just says
https://web.archive.org/web/20261004043057/https://yuka.dev/blog-2026-10-02-linux-m4.html works.
score 1 · canonical