Add std::panic::panic_any. #74622
Add std::panic::panic_any. #74622
Conversation
|
r? @shepmaster (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
To bikeshed the name a bit more, what about I'd personally prefer |
|
My own 2¢ on the name — I'd want |
|
Nominating to make @rust-lang/lang members aware of this. |
|
Regarding naming, I agree that something based on "value" is preferable to "box". The fact that boxing occurs doesn't feel like the important thing for users to keep in mind. I'm happy with |
nikomatsakis
added
T-libs-api
|
That said, we discussed this in the @rust-lang/lang meeting today and we felt like this sort of bikeshedding is really a @rust-lang/libs affair, so i'm going to retag this as T-libs. |
|
Could we separate the idea of having a separate macro for "panic with this specific value" from the "there's one argument and it's a string literal" case? I'd love to see the 2021-edition |
That doesn’t seem possible. As far as I know we cannot make macros behave differently based on the edition of the call site. (Editions are per-crate, so |
|
It would require compiler magic, I suppose, but only in a more general way, by adding something like |
|
☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts. |
|
So, it feels like we need to discuss this PR in the context of the full plan. As I understood it, the plan was this:
I forget what we would do about The hope was indeed that in 2021 Edition crates, the |
|
|
That's already taken care of by #74056 |
|
Why does |
|
@sfackler it doesn't, I think that was me just typing wrong |
|
@m-ou-se if you can resolve the conflicts, we can push this forward |
Dylan-DPC-zz
added
S-waiting-on-author
camelid
added
S-waiting-on-review
Co-authored-by: Camelid <camelidcamel@gmail.com>
|
We discussed this in the recent Libs meeting and felt happy with the name @bors r+ rollup |
|
📌 Commit b48fee0 has been approved by |
bors
added
S-waiting-on-bors
camelid
added
the
A-runtime
… r=KodrAus Add std::panic::panic_any. The discussion of rust-lang#67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private, unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any`, because it allows for any (`Any + Send`) type. _Tracking issue: #78500_
… r=KodrAus Add std::panic::panic_any. The discussion of rust-lang#67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private, unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any`, because it allows for any (`Any + Send`) type. _Tracking issue: #78500_
… r=KodrAus Add std::panic::panic_any. The discussion of rust-lang#67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private, unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any`, because it allows for any (`Any + Send`) type. _Tracking issue: #78500_
Rollup of 7 pull requests Successful merges: - rust-lang#74622 (Add std::panic::panic_any.) - rust-lang#77099 (make exp_m1 and ln_1p examples more representative of use) - rust-lang#78526 (Strip tokens from trait and impl items before printing AST JSON) - rust-lang#78550 (x.py setup: Create config.toml in the current directory, not the top-level directory) - rust-lang#78577 (validator: Extend aliasing check to a call terminator) - rust-lang#78581 (Constantify more BTreeMap and BTreeSet functions) - rust-lang#78587 (parser: Cleanup `LazyTokenStream` and avoid some clones) Failed merges: r? `@ghost`
…nt, r=estebank
Add lint for panic!("{}")
This adds a lint that warns about `panic!("{}")`.
`panic!(msg)` invocations with a single argument use their argument as panic payload literally, without using it as a format string. The same holds for `assert!(expr, msg)`.
This lints checks if `msg` is a string literal (after expansion), and warns in case it contained braces. It suggests to insert `"{}", ` to use the message literally, or to add arguments to use it as a format string.
This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later, once [`panic_any()`](rust-lang#74622) becomes a stable alternative.
The discussion of #67984 lead to the conclusion that there should be a macro or function separate from
std::panic!()for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021)std::panic!(arbitrary_payload).Alternative names:
panic_with!(..)start_unwind(..)throw!(..)panic_throwing!(..)panic_with_value(..)panic_value(..)panic_with(..)panic_box(..)panic(..)The equivalent (private, unstable) function in
libstdis calledstd::panicking::begin_panic.I suggest
panic_any, because it allows for any (Any + Send) type.Tracking issue: #78500