6 ms·

For panic detection or overflow detection there are static analysis solutions but I hope they get more integrated and standardized (as was attempted in cargo-ve

For panic detection or overflow detection there are static analysis solutions but I hope they get more integrated and standardized (as was attempted in cargo-verify)

sophacles 5y ago
I'd like to see a `#[no_panic]` tag similar to the `#[no_std]` one.
- vbezhenar 5y ago
  How to you expect it to work?
  - adament 5y ago
    Could you not enforce that functions tagged can only call other functions with the tag and must not call panic? This would not protect against stack overflow or similar environmental panics.
    - vbezhenar 5y ago
      That's the issue. Rust panics on division-by-zero, Rust panics on out-of-bounds, Rust panics on signed integer overflow in debug mode. Stack overflow can happen on every function call which is also panic. Too many implicit panic sources.
- woodruffw 5y ago
  Yep, exactly something like this! Implementation is the challenging part: the standard library and community ecosystem is full of legitimate uses of panic, and there are instances where panics might appear in the source code of dependencies but not in (optimized) builds.
  - nicoburns 5y ago
    > full of legitimate uses of panic Yes, but the whole point of `no_panic` is that in this context there are no legitimate uses of panic. If that means making a bunch of parallel APIs that return results for this super-correct code then so be it.
    - woodruffw 5y ago
      You're absolutely right. I meant primarily in terms of the challenge of writing panic-free code while still being a consumer of the crate ecosystem.
- pdimitar 5y ago
  That, or a subset of Rust that has all the panicking functions removed and only has std API that works with Result and Option.
- gpderetta 5y ago
  surely it should be #[DONT_PANIC] in large friendly letters.
  - dureuill 5y ago
    Or implied by the #[keep_calm] attribute
  - sophacles 5y ago
    Hah, nice one. I think we could get the unicode folks to accept an emoji form of this: https://thebullelephant.com/wp-content/uploads/2016/12/dontpanic.png https://thebullelephant.com/wp-content/uploads/2016/12/dontp... and alternately accept `#[$UNICODE_FOR_SAID_EMOJI]`.
    - chrismorgan 5y ago
      Rust doesn’t allow emoji in identifiers, following the UAX #31 rules. It would require a significant break in someone’s tradition to get such a thing through. … quite apart from the implausibility of getting such a character into Unicode in the first place.
- sebzim4500 5y ago
  Presumably using `#[no_panic]` would require `#[no_std]`? Would you be allowed to use unchecked arithmetic, which panics in dev builds but not release builds?
  - chrismorgan 5y ago
    Why would #[no_panic] require #[no_std]? There are perfectly legitimate reasons for not wanting panicking in code that uses std, and it’s possible to panic without std.

For panic detection or overflow detection there are static analysis solutions but I hope they get more integrated and standardized (as was attempted in cargo-verify)

sophacles 5y ago

I'd like to see a `#[no_panic]` tag similar to the `#[no_std]` one.

vbezhenar 5y ago
How to you expect it to work?
- adament 5y ago
  Could you not enforce that functions tagged can only call other functions with the tag and must not call panic? This would not protect against stack overflow or similar environmental panics.
  - vbezhenar 5y ago
    That's the issue. Rust panics on division-by-zero, Rust panics on out-of-bounds, Rust panics on signed integer overflow in debug mode. Stack overflow can happen on every function call which is also panic. Too many implicit panic sources.
woodruffw 5y ago
Yep, exactly something like this! Implementation is the challenging part: the standard library and community ecosystem is full of legitimate uses of panic, and there are instances where panics might appear in the source code of dependencies but not in (optimized) builds.
- nicoburns 5y ago
  > full of legitimate uses of panic Yes, but the whole point of `no_panic` is that in this context there are no legitimate uses of panic. If that means making a bunch of parallel APIs that return results for this super-correct code then so be it.
  - woodruffw 5y ago
    You're absolutely right. I meant primarily in terms of the challenge of writing panic-free code while still being a consumer of the crate ecosystem.
pdimitar 5y ago
That, or a subset of Rust that has all the panicking functions removed and only has std API that works with Result and Option.
gpderetta 5y ago
surely it should be #[DONT_PANIC] in large friendly letters.
- dureuill 5y ago
  Or implied by the #[keep_calm] attribute
- sophacles 5y ago
  Hah, nice one. I think we could get the unicode folks to accept an emoji form of this: https://thebullelephant.com/wp-content/uploads/2016/12/dontpanic.png https://thebullelephant.com/wp-content/uploads/2016/12/dontp... and alternately accept `#[$UNICODE_FOR_SAID_EMOJI]`.
  - chrismorgan 5y ago
    Rust doesn’t allow emoji in identifiers, following the UAX #31 rules. It would require a significant break in someone’s tradition to get such a thing through. … quite apart from the implausibility of getting such a character into Unicode in the first place.
sebzim4500 5y ago
Presumably using `#[no_panic]` would require `#[no_std]`? Would you be allowed to use unchecked arithmetic, which panics in dev builds but not release builds?
- chrismorgan 5y ago
  Why would #[no_panic] require #[no_std]? There are perfectly legitimate reasons for not wanting panicking in code that uses std, and it’s possible to panic without std.