Tracking Issue for RFC 3007: Making core and std's panic identical in Rust 2021

[m-ou-se]

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 for panic_any #78500, PR Stabilize std::panic::panic_any. #81194
• Add a lint for panicking on non-string-literals (and suggest panic_any): Add lint for panic!(123) which is not accepted in Rust 2021. #81645
• Update panic!() documentation about non-string-literals: Part of Add lint for panic!(123) which is not accepted in Rust 2021. #81645
• Throw a &str instead of a String in std when using core::panic!: Throw core::panic!("message") as &str instead of String. #78119
• Fix hygiene in todo!(), assert_eq!(), etc. to always use core::panic!(): Qualify panic! as core::panic! in non-built-in core macros #78343
• Fix assert!(expr, message) to call core's panic mechanism directly: Part of Add lint for panic!("{}") #78088
• Fix assert!(expr) to call core's panic mechanism directly in edition 2021: Expand assert!(expr, args..) to include $crate for hygiene on 2021. #80855
• Make {std, core}::panic!(..) always use format_args!(..) in edition 2021: Implement Rust 2021 panic #80851
  • This needs Allow #[rustc_builtin_macro = "name"] #80850.
• Make std::panic!(..) an alias for core::panic!(..) in edition 2021: Make std::panic!() identical to core::panic!() on Rust 2021 #80879 Included in Implement Rust 2021 panic #80851.
  • This requires core::panic!() cannot be used everywhere std::panic!() can. #80846 to be fixed first
• Update panic_fmt lint to mention edition 2021: Part of Add lint for panic!(123) which is not accepted in Rust 2021. #81645
• Fix 2021's assert!(123, "{}") expanding to the wrong edition of panic!(): Fix bug with assert!() calling the wrong edition of panic!(). #81647
• Rename the panic_fmt lint to non_fmt_panic (see Add lint for panic!("{}") #78088 (comment)): Part of Add lint for panic!(123) which is not accepted in Rust 2021. #81645, beta backport in [beta] Rename panic_fmt lint to non_fmt_panic #81729

[rodrimati1992]

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 str constant at compile-time?

I made the const_format crate 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 str to have my own static assertion macros.

[m-ou-se]

@rodrimati1992 Panicking at compile is unstable, both before and after these changes. The current unstable implementation of const_panic will not work right away with the new 2021 version of panic!(), as panic!(SOME_CONST) is no longer accepted. The 2021 version of the panic!() macro will accept the exact same arguments as the println!() 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:

• Use core::panicking::panic instead of the panic!() macro (which is unstable, but so is const_panic) or
• Extend const_panic to understand at least panic!("{}", SOME_CONSTANT), or
• Implement format_args!() could 'inline' literal arguments #78356.

[m-ou-se]

@rodrimati1992 By the way, note that core::panic!(SOME_CONST) in const_panic in the current editions was fixed and works now. Also, if your crate uses edition 2018 and has a macro that expands to panic!(..), it would always be the 2018 version of panic!(), even if the crate that uses your macro is a 2021 crate.

[m-ou-se]

Done!

🎉

[djugei]

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.:

const ERR_ALPHA: &'static str = "alpha error";
panic!(ERR_ALPHA);

this can be easily resolved in user code by writing

panic!("{}", ERR_ALPHA};

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]

@djugei #78356 would help with that. Ideally, format_args!("{}", ERR_ALPHA) results in the same trivial fmt::Arguments as format_args!("alpha error") with a .as_str() returning Some("alpha error") to avoid any formatting.

Depending on how far away we think that is, we could consider stabilizing panic_str in the meantime.

[djugei]

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.