-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Permit const panics in stable const contexts in stdlib #90687
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
I don't think this should or need to be backported. |
a56c6e8
to
c49d741
Compare
As this only affects stdlib and I've confirmed that #89542 compiles after being rebased on this PR, I agree it doesn't need to be backported. I still think this would be nice to prioritize given that it's blocking other things, but feel free to remove the I-prioritize label if wanted. The actual change is all of one line — the rest is just testing and small idiomatic changes in |
r? @oli-obk this is solely an internal change and it is definitely intended that we can use @bors r+ I don't think we should prioritize/backport things just to unblock stabilizing others. There is no rush to stabilize things, but I get how annoying it is when things are blocked. |
📌 Commit 6d2f8af has been approved by |
…askrgr Rollup of 8 pull requests Successful merges: - rust-lang#89610 (warn on must_use use on async fn's) - rust-lang#90667 (Improve diagnostics when a static lifetime is expected) - rust-lang#90687 (Permit const panics in stable const contexts in stdlib) - rust-lang#90772 (Add Vec::retain_mut) - rust-lang#90861 (Print escaped string if char literal has multiple characters, but only one printable character) - rust-lang#90884 (Fix span for non-satisfied trivial trait bounds) - rust-lang#90900 (Remove workaround for the forward progress handling in LLVM) - rust-lang#90901 (Improve ManuallyDrop suggestion) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Just to clarify w.r.t. backporting: don't. Other things don't need to wait for this to hit beta as I originally suspected. |
Without this change, it is not possible to use
panic!
and similar (includingassert!
) in stable const contexts inside of stdlib. See #89542 for a real-world case that currently fails for this reason. This does not affect any user code.For example, this snippet currently fails to compile:
With the addition of
#[rustc_const_unstable]
tocore::panicking::panic
, the error no longer occurs. This snippet has been added verbatim in this PR as a UI test.To avoid needing to add
#![feature(core_panic)]
to libcore, the two instances of direct calls tocore::panicking::panic
have been switched to use thepanic!
macro.I am requesting prioritization because this is holding up other stabilizations such as #89542 (which is otherwise ready to merge and succeeds with this change)