panic!("{}") shouldn't compile

[tomaka]

I didn't find any duplicate issue, but this problem has probably been there for a long time.

• The code panic!("{}", 7) compiles and prints thread <main> panicked at "7", ...
• The code panic!("{} {}", 7) doesn't compile as an argument is missing
• The code panic!("{}") does compile and prints thread <main> panicked at "{}", ...

The last one doesn't detect potential mistakes, and is inconsistent with println!("{}") which doesn't compile.

[amaneureka]

Actually this is not an issue; If you go through the docs (http://doc.rust-lang.org/std/macro.panic!.html)
"The multi-argument form of this macro panics with a string and has the format! syntax for building a string."
So, In the code panic!("{}", 7) you are calling multi-argument form of this macro. Same for panic!("{} {}", 7) Here Format! syntax will be followed, And that is why the code doesn't compile.
Now panic!("{}") This is a single-argument form of this macro, so it gonna to be treated as plain string. Hence it got compiled and prints thread <main> panicked at "{}", ....
In case of println!("{}") it is clearly stated in API docs that, println uses Format! syntax irrespective weather it is a multi-argument or not.

[tomaka]

I know why it compiles, but it's still an issue.

[rprichard]

It'd be nice if we could remove the inconsistency between single-argument and multiple-argument panic! macros. It's easy if we make single-argument panic! call core::panicking::panic_fmt, but that would add massive bloat to the panic! call sites.

This same issue came up in #22335, which tried to optimize write*! and print*! in the same way that panic! is already optimized. After stumbling onto the inconsistency, the author added a format_arg! that evaluates to a &'static str. As a new macro, it needed an RFC.

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.

[rprichard]

The same inconsistency also applies to assert!:

    assert!(1 == 2, "{}");          // prints: '{}'
    assert!(1 == 2, "{}", 1234);    // prints: '1234'

Currently the one-argument assert! just calls panic!(concat!("assertion failed: ", stringify!($cond))), so fixing panic! would break assert! on this code:

    assert!("abc" == "{}");         // prints: 'assertion failed: "abc" == "{}"'

Probably easy to fix.

[pnkfelix]

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.

[rprichard]

If we make single-argument panic! use the formatting system like write!, then we need an alternate syntax for the current single-argument panic! in libstd, so we can still do things like:

panic!({ let x = "{}"; x })
panic!(7)

Maybe add a panic_arg! or panic_any! macro?

The other thing needed for this issue is some way to convert a format string to an output string:

• A new format_arg! macro. (I suggest format_args_literal! as an alternate name.)
• Use format_args! and a new method on Arguments to extract the lone string piece. It will probably generate larger code then the previous option, but not worse than the current libstd panic!. We'd like to place the string piece in a static item, like core::panicking::panic does, but we can't have a function call in a static. This approach would generate a lot more code at each call-site, but it ought to be optimized out.

I benchmarked the size overhead of calling panic! with a single-argument on x86_64. It's 52 bytes in libcore and 67 bytes in libstd. Calling core::panicking::panic_fmt takes 110 bytes.

[rprichard]

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 assert_eq! for consistency (or maybe they should all use plain assert!). The test still checks the right thing anyway. I'll submit a PR.

What I was trying to find was a place invoking assert! with the intent to panic with a non-string value. That usage would break if panic! were split into two macros. (I did find one place passing a non-constant string as the second assert! argument, but it could be fixed using a "{}" format.)

What if we changed the non-formatting panic! by inserting a token at the front, maybe panic!(msg 7), in which case one could also write assert!(condition, msg 7)?

[alexcrichton]

triage: P-high

I think the panic!(anything) aspect of panic! will make quite hard to overcome a limitation such as this, and I also think that we should audit whether that's actually an interface we want to support at this time.

[rprichard]

@alexcrichton In case it matters for bookkeeping: GitHub is still labeling this issue P-low, despite your triage: P-high comment.