You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The no_panic attribute macro is a very handy way to ensure that code which you think is sound really truly is.
Given that a fundamental rule of the parser is to never panic, even in the presence of outright malicious input, this tool seems very helpful.
How can this possibly work?
The full details can be found in the source code, but the TL;DR is that the no_panic macro checks that the compiler itself has optimized out any and all branches of the decorated function which could potentially panic.
This strategy is effective, but it has minor drawbacks as well.
Code which is naively annotated no_panic will not compile in debug builds (or any build which is doing insufficient optimization to allow the compiler to elide the paths which might panic). You can work around this limitation by using #[cfg_attr(not(debug_assertions), no_panic)] instead of just #[no_panic].
Just because the compiler can't prove that something is true does not mean that it is false.
It may be that your function really truly does not ever panic, but that the compiler can't prove it.
In those cases we need to use other strategies like kani (which I would also like to bring in now that we are using bolero)
The text was updated successfully, but these errors were encountered:
The no_panic attribute macro is a very handy way to ensure that code which you think is sound really truly is.
Given that a fundamental rule of the parser is to never panic, even in the presence of outright malicious input, this tool seems very helpful.
How can this possibly work?
The full details can be found in the source code, but the TL;DR is that the
no_panic
macro checks that the compiler itself has optimized out any and all branches of the decorated function which could potentially panic.This strategy is effective, but it has minor drawbacks as well.
no_panic
will not compile in debug builds (or any build which is doing insufficient optimization to allow the compiler to elide the paths which might panic). You can work around this limitation by using#[cfg_attr(not(debug_assertions), no_panic)]
instead of just#[no_panic]
.It may be that your function really truly does not ever panic, but that the compiler can't prove it.
In those cases we need to use other strategies like kani (which I would also like to bring in now that we are using bolero)
The text was updated successfully, but these errors were encountered: