Feature gate: `#![feature(breakpoint)]` This is a tracking issue for the `breakpoint` feature, which gates the `core::arch::breakpoint` function. This feature was approved in [ACP 491](https://github.com/rust-lang/libs-team/issues/491). ### Public API ```rust // core::arch /// Compiles to a target-specific software breakpoint instruction or equivalent. /// /// (Long description elided.) #[inline(always)] pub fn breakpoint() { unsafe { core::intrinsics::breakpoint(); } } ``` ### Steps / History - [x] ACP: https://github.com/rust-lang/libs-team/issues/491 - [x] Implementation: https://github.com/rust-lang/rust/pull/133726 - [x] Final comment period (FCP)[^1] - [ ] Stabilization PR with lang FCP - https://github.com/rust-lang/rust/pull/142325 <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilization PR can be opened by anyone. --> ### Unresolved Questions <!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --> - None yet. [^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html