Opt-in `panic` logging cost with `log_panic_values` build option and attribute

[ironcev]

Motivation

Not surprisingly, observing real-life projects shows that using error enums with all unit variants is the preferred way to model errors. In terms of code readability, maintenance, etc. it is definitely the right abstraction for error modelling.

A current disadvantage of this approach is that it doesn't play well with the panic expression. A very typical code like:

panic OrderCreationError::InvalidAsset;

will end up logging OrderCreationError::InvalidAsset. This means encoding the variant, and calling log. Even after #7496 we can still have a situation of enclosing enum type not being trivially encodeable (some variants might be non-unit). And even for trivially encodeable types, we will still call a logd instruction and create a receipt for a case where having only the corresponding error message in case of panicking is sufficient and very likely expected behavior.

Currently, the only way to avoid the overhead of logging is to use hardcoded strs:

panic "The provided asset was invalid.";

This breaks the error enums pattern and can lead to unwanted code duplications (currently strs cannot be reusable constants). E.g., the above OrderCreationError::InvalidAsset appears twice in the inspected code, and some OrderCreationError variants more than twice.

Proposed solution

log_panic_values build option

To support the enum error pattern but with zero cost by default or opted-in cost if desirable, the proposal is to implement the log_panic_values build option and the #[log_panic_values] attribute. Those would serve the similar purpose like the backtrace build option and the #[trace] attribute for the ABI backtracing - empowering developers to opt-in or out of a cost.

log_panic_values build option would have the below values that govern the compiler's behavior when it encounter the code like this:

panic SomeError::SomeUnitVariant;
panic SomeError::SomeNonUnitVariant(variable);

Value	Meaning
only_non_unit	Log enum variant only if it is a non-unit one. This is the default option for the release build. It ensures that a potentially relevant information is logged. For unit values, we assume that the error message, location, and the backtrace is what the end dev wants to see, and the unit enum variant is superfluous.
always	Always log enum variant. This is the default option for the debug build.
never	Never log enum variant. This option strips off any logging overhead, but stills keeps the zero-cost error message and panic location as well as negligible-cost backtrace if wanted.

[log_panic_values(<option>)] attribute

The #[log_panic_values(<option>)] attributes could be applied on functions to locally override the build option. The override applies only on panic expressions in that function, not in the functions it calls. We emit a warning if the attribute is applied on a function that does not have any panic expression.

The <option>s for attribute are the same as for the build option, with addition of one option exclusive to the attribute: never_on_only_non_unit.

never_if_only_non_unit attribute argument

never_if_only_non_unit would locally override the only_non_unit option and turn it into never instead. This is useful for library development where we want to provide rich errors with arguments in non-release builds, but go to zero-cost message in release build.

E.g., in the case of overflow, the <u8 as Add>::add could emit the actual numbers being added together with the message in the debug build:

panic U8OpsError::Overflow((a, b));

In the release build the above line will always compile to just a single rvrt.

Note that in the case of panicking an a variant unknown at compile-time, we by default log, unless the applicable log_panic_values is never (or never_if_only_non_unit when the build option is only_non_unit). E.g.:

panic some_error_var;

Drawbacks

The only drawback I see is the increased overall complexity of the panic language feature.

However, the meaningful defaults provide expected behavior for the majority of usages. Similar to the backtrace build option and the #[trace] attribute, most of the developers will never need to use the feature. Zero-cost will just be there.

Still, in advanced scenarios and library development, they can benefit from having the full control over the logging cost of panic expression.

[xunilrj]

I think we may have an easier solution.

If I am not mistaken we try to "const eval" the panic object only when it is a string slice. But the truth is that we can try "const eval" it every time. encode is guaranteed to be const because this is what we do for configurables.

So, if the panic object is indeed const, we just need to generate a logd pointing to the data section directly.

[ironcev]

encode is guaranteed to be const because this is what we do for configurables. So, if the panic object is indeed const, we just need to generate a logd pointing to the data section directly.

I wasn't aware of this! Shame on me because once you've mentioned it I recalled our discussion in person on encoding/decoding slice specific entrinsics. It was some time ago, if that's an excuse 😄

In fact, in #7493 I wrote this and thought of discussing it with you, unaware that it's already implemented:

If the error enum instance is known at compile time, compiler can generate the slice at compile time and emit only the log with that slice, instead if encoding it at runtime.

It's great to see we can do this optimization immediately and dramatically cut the cost presented in #7493.

---

However, this proposal is panic specific and tackles more then only lowering the cost of logging.

Once we apply the above optimization, the cost will be minimal but still there:

• three instructions to prepare registers for logd,
• logd itself,
• minimal bloat of the data section,
• creating a log receipt that is not needed.

Moreover, those four additional instructions will in many cases affect inlining which is currently based only on the number of instructions (something we also want to improve with better heuristics, but that's a separate topic).

Why to have that cost if it's not necessary and we can eliminate it by default without any need for devs to actively apply a concept?

The elimination of this cost does not create any cognitive burden by default. Only in case of advanced scenarios devs can actively use the feature to get full control.

It's important to notice, that the proposal is not only about error values that can be const-evaled. The only important thing is to be able to detect the exact enum variant at the compile time.

This gives us possibility for the never_if_only_non_unit feature, where we log non-const runtime values, but can detect the enum variant at compile time:

panic U8OpsError::Overflow((var_a, var_b));

I thought quite some about this looking at the current usages of reverting patterns in our std and in real-life projects. Empowering library devs to provide very detailed error information in debug mode while knowing that it will collapse to just a single rvrt I find very powerful and useful. And not only for library developers. Experienced app developers can use it as well, emitting rich debugging info during development and by using #[log_panic_values(never_if_only_non_unit)] removing it completely in release builds. Adding the support for the attribute on error types would simplify this use case even more.

Last but not least, in highest performance demanding scenarios this feature gives control to fully strip off all the logging and still preserve the error message and error location completely free of cost and without changing anything in code, just by setting the build option.

To end with a personal note, I indeed have a strong incline towards this philosophy of removing unnecessary cost by default if it doesn't bring mandatory burden for developers, while giving possibility for a full control in advanced scenarios like, e.g., high performance and library development.

[ironcev]

One additional thing I forgot to mention, removing the cost by default and giving the control over it to the end-developer removes the constraints imposed on library developers in the Error Handling RFC.

With log_panic_values in place, library developers can freely formulate errors and use error enums while staying sure using those will impose no cost for the end-applications. Manually enforcing strict guidelines currently proposed in the RFC becomes obsolete. We are, so to say, replacing self-discipline with a compiler feature.