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:
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?
Huh. What’s the benefit of breakpoint() never returning? A big part of a debugger is not just examining the state of a program at one point in time, but also stepping through code or fully resuming execution…
So it’s not that breakpoint would not be allowed to return, but that you get decide whether or not it’s allowed on a case-by-case basis, with the default being “nope”. I guess I kind of see the point, then, though it’s still surprising.
The point of the initiative is to beat print debugging. It’s not going to happen if the intrinsic can only be used on the nightly toolchain :)
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 afterbreakpointreturns, or is the user interacting with the debugger wrong to ask the program to continue after thisbreakpoint?score 2 · canonical
Huh. What’s the benefit of
breakpoint()never returning? A big part of a debugger is not just examining the state of a program at one point in time, but also stepping through code or fully resuming execution…Edit: found the tracking issue https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/issues/133724
So it’s not that breakpoint would not be allowed to return, but that you get decide whether or not it’s allowed on a case-by-case basis, with the default being “nope”. I guess I kind of see the point, then, though it’s still surprising.
score 4 · canonical