-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std: Destabilize the internals of panic! #24212
Conversation
Now that we have a `#[allow_internal_unstable]` attribute for macros there's no need for these two `begin_unwind` functions to be stable. Right now the `panic!` interface is the only one we wish to stabilize, so remove the stability markers from these functions. While this is a breaking change, it is highly unlikely to break any actual code. It is recommended to use the `panic!` macro instead if it breaks explicit calls into `std::rt`. [breaking-change] cc rust-lang#24208
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
@@ -495,7 +495,6 @@ pub extern fn rust_begin_unwind(msg: fmt::Arguments, | |||
/// on (e.g.) the inlining of other functions as possible), by moving | |||
/// the actual formatting into this shared place. | |||
#[inline(never)] #[cold] | |||
#[stable(since = "1.0.0", feature = "rust1")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these need explicit #[unstable]
annotations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unstable
inherits (in this case from std::rt
).
@bors r+ |
📌 Commit 65e3f03 has been approved by |
Aren't the pretty printing tests going to fail? #23616. |
@rprichard you are most correct! re-r? @huonw, I just deleted |
@bors r+ |
📌 Commit 704f628 has been approved by |
704f628
to
f4270c8
Compare
This commit removes pretty-expanded from all tests that wind up calling panic! one way or another now that its internals are unstable.
f4270c8
to
ec7c800
Compare
…nd, r=huonw Now that we have a `#[allow_internal_unstable]` attribute for macros there's no need for these two `begin_unwind` functions to be stable. Right now the `panic!` interface is the only one we wish to stabilize, so remove the stability markers from these functions. While this is a breaking change, it is highly unlikely to break any actual code. It is recommended to use the `panic!` macro instead if it breaks explicit calls into `std::rt`. [breaking-change] cc rust-lang#24208
…nd, r=huonw Now that we have a `#[allow_internal_unstable]` attribute for macros there's no need for these two `begin_unwind` functions to be stable. Right now the `panic!` interface is the only one we wish to stabilize, so remove the stability markers from these functions. While this is a breaking change, it is highly unlikely to break any actual code. It is recommended to use the `panic!` macro instead if it breaks explicit calls into `std::rt`. [breaking-change] cc rust-lang#24208
Now that we have a
#[allow_internal_unstable]
attribute for macros there's noneed for these two
begin_unwind
functions to be stable. Right now thepanic!
interface is the only one we wish to stabilize, so remove the stability markers
from these functions.
While this is a breaking change, it is highly unlikely to break any actual code.
It is recommended to use the
panic!
macro instead if it breaks explicit callsinto
std::rt
.[breaking-change]
cc #24208