Repository navigation
Tracking Issue for RFC 3007: Making core and std's panic identical in Rust 2021 #80162
Description
This is a tracking issue for RFC 3007 "Plan to make core and std's panic identical": rust-lang/rfcs#3007
Steps
- Add a lint for format strings incompatible with the edition change: Add lint for panic!("{}") #78088
- Add
std::panic::panic_any: Add std::panic::panic_any. #74622 - Stabilize
std::panic::panic_any: Tracking issue Tracking Issue forpanic_any#78500, PR Stabilize std::panic::panic_any. #81194 - Add a lint for panicking on non-string-literals (and suggest
panic_any): Add lint forpanic!(123)which is not accepted in Rust 2021. #81645 - Update
panic!()documentation about non-string-literals: Part of Add lint forpanic!(123)which is not accepted in Rust 2021. #81645 - Throw a
&strinstead of aStringinstdwhen usingcore::panic!: Throw core::panic!("message") as &str instead of String. #78119 - Fix hygiene in
todo!(),assert_eq!(), etc. to always usecore::panic!(): Qualifypanic!ascore::panic!in non-built-incoremacros #78343 - Fix
assert!(expr, message)to callcore's panic mechanism directly: Part of Add lint for panic!("{}") #78088 - Fix
assert!(expr)to callcore's panic mechanism directly in edition 2021: Expand assert!(expr, args..) to include $crate for hygiene on 2021. #80855 - Make
{std, core}::panic!(..)always useformat_args!(..)in edition 2021: Implement Rust 2021 panic #80851- This needs Allow #[rustc_builtin_macro = "name"] #80850.
- Make
std::panic!(..)an alias forcore::panic!(..)in edition 2021:MakeIncluded in Implement Rust 2021 panic #80851.std::panic!()identical tocore::panic!()on Rust 2021 #80879-
This requires core::panic!() cannot be used everywhere std::panic!() can. #80846 to be fixed first
-
- Update
panic_fmtlint to mention edition 2021: Part of Add lint forpanic!(123)which is not accepted in Rust 2021. #81645 - Fix 2021's
assert!(123, "{}")expanding to the wrong edition ofpanic!(): Fix bug with assert!() calling the wrong edition of panic!(). #81647 - Rename the
panic_fmtlint tonon_fmt_panic(see Add lint for panic!("{}") #78088 (comment)): Part of Add lint forpanic!(123)which is not accepted in Rust 2021. #81645, beta backport in [beta] Renamepanic_fmtlint tonon_fmt_panic#81729
Reacted by Robin Freyler, Samuel Tardieu and Felipe S. S. Schneider
Reacted by Igor Matuszewski, Diana, Eric Shimizu Karbstein, Safin Singh, Shirshak and Felipe S. S. Schneider
Reacted by Diana, Eric Shimizu Karbstein, Jason Miller, Safin Singh, Shirshak, Mathspy, Felipe S. S. Schneider and Christian Hudon
Activity
rodrimati1992 commentedon Jan 11, 2021
I'm a little confused about what's supported with these changes.
Do the changes here allow you to panic in
#![no_std]crates with a non-literal&'static strconstant at compile-time?I made the
const_formatcrate to allow me to do string formatting at compile-time before the standard library can do it, and need to be able to panic with a non-literal&'static strto have my own static assertion macros.m-ou-se commentedon Jan 12, 2021
@rodrimati1992 Panicking at compile is unstable, both before and after these changes. The current unstable implementation of
const_panicwill not work right away with the new 2021 version ofpanic!(), aspanic!(SOME_CONST)is no longer accepted. The 2021 version of thepanic!()macro will accept the exact same arguments as theprintln!()macro. That is, the first argument must be a format string as string literal.Options for panicking at compile time with a non-literal string message in Rust 2021:
core::panicking::panicinstead of thepanic!()macro (which is unstable, but so isconst_panic) orconst_panicto understand at leastpanic!("{}", SOME_CONSTANT), orm-ou-se commentedon Jan 12, 2021
@rodrimati1992 By the way, note that
core::panic!(SOME_CONST)inconst_panicin the current editions was fixed and works now. Also, if your crate uses edition 2018 and has a macro that expands topanic!(..), it would always be the 2018 version ofpanic!(), even if the crate that uses your macro is a 2021 crate.4 remaining items
Auto merge of rust-lang#80851 - m-ou-se:panic-2021, r=petrochenkov
Rollup merge of rust-lang#81645 - m-ou-se:panic-lint, r=estebank
Auto merge of #80851 - m-ou-se:panic-2021, r=petrochenkov
Rollup merge of rust-lang#81645 - m-ou-se:panic-lint, r=estebank,flip…
Rollup merge of rust-lang#81645 - m-ou-se:panic-lint, r=estebank,flip…
Rollup merge of rust-lang#81645 - m-ou-se:panic-lint, r=estebank,flip…
Rollup merge of rust-lang#81645 - m-ou-se:panic-lint, r=estebank,flip…
Rollup merge of rust-lang#81645 - m-ou-se:panic-lint, r=estebank,flip…
m-ou-se commentedon Feb 6, 2021
Done!
🎉
utils: fix rust 2021 warnings
djugei commentedon Jul 28, 2021
bit of a late comer, seeing that this rfc has already been accepted, but:
defining shared error messages now results in a warning, i.e.:
this can be easily resolved in user code by writing
but no actual formatting is needed, i just want to push a string literal to stderr. this especially means that i would like to avoid pulling in the format machinery if at all possible, because it has a noticeable impact on binary size.
m-ou-se commentedon Jul 28, 2021
@djugei #78356 would help with that. Ideally,
format_args!("{}", ERR_ALPHA)results in the same trivialfmt::Argumentsasformat_args!("alpha error")with a.as_str()returningSome("alpha error")to avoid any formatting.Depending on how far away we think that is, we could consider stabilizing
panic_strin the meantime.djugei commentedon Jul 28, 2021
Ah, thanks i had not found panic_str (hidden under 2 layers of nightly), im ok with using nightly for now. Some const evaluation of format args could be cool though.