panic!("{}") shouldn't compile #22932
Comments
kmcallister
added
A-libs
A-macros
|
Actually this is not an issue; If you go through the docs (http://doc.rust-lang.org/std/macro.panic!.html) |
|
I know why it compiles, but it's still an issue. |
|
It'd be nice if we could remove the inconsistency between single-argument and multiple-argument This same issue came up in #22335, which tried to optimize I'm interested in this stuff right now because I'm working on a bootloader, and the overhead of the panic formatting code is giving me trouble -- http://users.rust-lang.org/t/fixed-overhead-rust-bootloader-and-core-panicking/429/10. |
|
The same inconsistency also applies to assert!(1 == 2, "{}"); // prints: '{}'
assert!(1 == 2, "{}", 1234); // prints: '1234'Currently the one-argument assert!("abc" == "{}"); // prints: 'assertion failed: "abc" == "{}"'Probably easy to fix. |
|
1.0 polish; P-low. If this gets fixed by 1.0, great; but if we shipped 1.0 with this semantics, its not the end of the world. |
|
If we make single-argument panic!({ let x = "{}"; x })
panic!(7)Maybe add a The other thing needed for this issue is some way to convert a format string to an output string:
I benchmarked the size overhead of calling |
|
I found a mistake in a libstd test case that would presumably have been avoided were this issue fixed: assert_eq!((0 as $T).is_power_of_two(), false);
assert_eq!((1 as $T).is_power_of_two(), true);
assert_eq!((2 as $T).is_power_of_two(), true);
assert_eq!((3 as $T).is_power_of_two(), false);
assert_eq!((4 as $T).is_power_of_two(), true);
assert_eq!((5 as $T).is_power_of_two(), false);
assert!(($T::MAX / 2 + 1).is_power_of_two(), true);The last line should be What I was trying to find was a place invoking What if we changed the non-formatting |
|
triage: P-high I think the |
|
@alexcrichton In case it matters for bookkeeping: GitHub is still labeling this issue P-low, despite your triage: P-high comment. |
|
hehe, but it appears to have picked up your comment :) |
|
We need a patch to appear for this very soon for it to happen. |
|
I guess we also need a firm decision. |
|
Another question to consider: if we change single-argument I'm happy to write a patch, but I feel like it needs an RFC, and I haven't seen any discussion of this issue. Does it need to be posted on the forum? |
|
It prints I'd rather add a |
|
I created a post on the forum. http://internals.rust-lang.org/t/panic-shouldnt-compile/1851 |
|
Majority of the team says they want to preserve much of the existing behavor -- i.e. support passing a single arbitrary value, but also support the formatting form. The main strategy that was supported was to catch this error case (where a string-literal template string is being passed as the single argument, and it has placeholder braces), as a special case (perhaps via a lint) and only reject that case. E.g. any non string-literal unary input to |
|
(I think I have something put together to address this.) |
To accomplish this, adds `ensure_not_fmt_string_literal!` macro that
will fail the compile if its argument is a fmt string literal.
`ensure_not_fmt_string_literal!` takes a name along with expr; this
allows for better error messages at its usage sites (like `panic!`).
----
Since this is making a certain kind of use of `panic!` illegal, it
is a:
[breaking-change]
In particular, a panic like this:
```rust
panic!("Is it stringified code: { or is it a ill-formed fmt arg? }");
```
must be rewritten; one easy rewrite is to add parentheses:
```rust
panic!(("Is it stringified code: { or is it a ill-formed fmt arg? }"));
```
----
Fix rust-lang#22932.
Ensure a sole string-literal passed to `panic!` is not a fmt string.
To accomplish this, adds `ensure_not_fmt_string_literal!` macro that will fail the compile if its expression argument is a fmt string literal.
Since this is making a certain kind of use of `panic!` illegal, it is a:
[breaking-change]
In particular, a panic like this:
```rust
panic!("Is it stringified code: { or is it a ill-formed fmt arg? }");
```
must be rewritten; one easy rewrite is to add parentheses:
```rust
panic!(("Is it stringified code: { or is it a ill-formed fmt arg? }"));
```
----
Fix #22932.
Ensure a sole string-literal passed to `panic!` is not a fmt string.
To accomplish this, adds `ensure_not_fmt_string_literal!` macro that will fail the compile if its expression argument is a fmt string literal.
Since this is making a certain kind of use of `panic!` illegal, it is a:
[breaking-change]
In particular, a panic like this:
```rust
panic!("Is it stringified code: { or is it a ill-formed fmt arg? }");
```
must be rewritten; one easy rewrite is to add parentheses:
```rust
panic!(("Is it stringified code: { or is it a ill-formed fmt arg? }"));
```
----
Fix #22932.
To accomplish this, adds `ensure_not_fmt_string_literal!` macro that
will fail the compile if its argument is a fmt string literal.
`ensure_not_fmt_string_literal!` takes a name along with expr; this
allows for better error messages at its usage sites (like `panic!`).
----
Since this is making a certain kind of use of `panic!` illegal, it
is a:
[breaking-change]
In particular, a panic like this:
```rust
panic!("Is it stringified code: { or is it a ill-formed fmt arg? }");
```
must be rewritten; one easy rewrite is to add parentheses:
```rust
panic!(("Is it stringified code: { or is it a ill-formed fmt arg? }"));
```
----
Fix rust-lang#22932.
To accomplish this, adds `ensure_not_fmt_string_literal!` macro that
will fail the compile if its argument is a fmt string literal.
`ensure_not_fmt_string_literal!` takes a name along with expr; this
allows for better error messages at its usage sites (like `panic!`).
----
Since this is making a certain kind of use of `panic!` illegal, it
is a:
[breaking-change]
In particular, a panic like this:
```rust
panic!("Is it stringified code: { or is it a ill-formed fmt arg? }");
```
must be rewritten; one easy rewrite is to add parentheses:
```rust
panic!(("Is it stringified code: { or is it a ill-formed fmt arg? }"));
```
----
Fix rust-lang#22932.
Ensure a sole string-literal passed to `panic!` is not a fmt string.
To accomplish this, adds `ensure_not_fmt_string_literal!` macro that will fail the compile if its expression argument is a fmt string literal.
Since this is making a certain kind of use of `panic!` illegal, it is a:
[breaking-change]
In particular, a panic like this:
```rust
panic!("Is it stringified code: { or is it a ill-formed fmt arg? }");
```
must be rewritten; one easy rewrite is to add parentheses:
```rust
panic!(("Is it stringified code: { or is it a ill-formed fmt arg? }"));
```
----
Fix #22932.
To accomplish this, adds `ensure_not_fmt_string_literal!` macro that
will fail the compile if its argument is a fmt string literal.
`ensure_not_fmt_string_literal!` takes a name along with expr; this
allows for better error messages at its usage sites (like `panic!`).
----
Since this is making a certain kind of use of `panic!` illegal, it
is a:
[breaking-change]
In particular, a panic like this:
```rust
panic!("Is it stringified code: { or is it a ill-formed fmt arg? }");
```
must be rewritten; one easy rewrite is to add parentheses:
```rust
panic!(("Is it stringified code: { or is it a ill-formed fmt arg? }"));
```
----
Fix rust-lang#22932.
To accomplish this, adds `ensure_not_fmt_string_literal!` macro that
will fail the compile if its argument is a fmt string literal.
`ensure_not_fmt_string_literal!` takes a name along with expr; this
allows for better error messages at its usage sites (like `panic!`).
----
Since this is making a certain kind of use of `panic!` illegal, it
is a:
[breaking-change]
In particular, a panic like this:
```rust
panic!("Is it stringified code: { or is it a ill-formed fmt arg? }");
```
must be rewritten; one easy rewrite is to add parentheses:
```rust
panic!(("Is it stringified code: { or is it a ill-formed fmt arg? }"));
```
----
Fix rust-lang#22932.
|
(The backwards-compatible strategy for addressing this would be to just warn when format string literal is passed to unary |
|
Triage: this does reproduce today, printing |
brson
added
the
T-libs-api
|
This is very similar to the recently closed #30143, so I'm going to tag this as such (rust-2-breakage-wishlist) and close. |
alexcrichton
added
the
rust-2-breakage-wishlist
|
This is fixed in Rust 2021, so no rust-2-breakage-wishlist label is needed. |
fee1-dead
removed
the
rust-2-breakage-wishlist
I didn't find any duplicate issue, but this problem has probably been there for a long time.
panic!("{}", 7)compiles and printsthread <main> panicked at "7", ...panic!("{} {}", 7)doesn't compile as an argument is missingpanic!("{}")does compile and printsthread <main> panicked at "{}", ...The last one doesn't detect potential mistakes, and is inconsistent with
println!("{}")which doesn't compile.The text was updated successfully, but these errors were encountered: