3 ms·

This seems..absurd for a programming language with goals like Rust. Why isn't this a compiler option? Just set -nopanics and the compiler errors and flags anyth

by XorNot 2y ago

This seems..absurd for a programming language with goals like Rust. Why isn't this a compiler option? Just set -nopanics and the compiler errors and flags anything which is pulling in a panic at the very least?

dccsillag 2y ago
Yeah, I'm fairly sure that there is such a flag/toplevel attribute... and if there isn't, there should be one. It also feels like most of the pains on avoiding panics centers around allocations which, though a bit unfortunate, makes sense; it was an intentional design choice to make allocations panic instead of return Results, because most users of the language would probably crash on allocation fails anyways and it would introduce a lot of clutter. There was some effort some while ago on having better fallible allocations, but I'm not sure what happened over there.
dpc_01234 2y ago
https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html#unrecoverable-errors-with-panic https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-... ``` [profile.release] panic = 'abort' ```
- rcxdude 2y ago
  that just makes the panics unrecoverable. It doesn't statically guarantee no panics.
  - lmm 2y ago
    It presumably avoids the linked in 300Kb that was supposedly part of the motivation for doing this though?
  - wongarsu 2y ago
    There is no-panic [1] to turn panics in a function into compile errors, or the older no-panics-whatsoever [2] to do the same for the entire binary 1: https://crates.io/crates/no-panic https://crates.io/crates/no-panic 2: https://crates.io/crates/no-panics-whatsoever https://crates.io/crates/no-panics-whatsoever
    - themulticaster 2y ago
      no-panic uses link-time shenanigans to prevent panics in the compiled binary, but this isn't 100% reliable (as explained in the README, just pointing this out)
- surajrmal 2y ago
  After using rust for several years, I'm shocked this isn't the default. Making panics recoverable leads to them being used incorrectly.
  - exDM69 2y ago
    Panics also unwind the stack and run all your Drop destructors. Setting `panic = abort` disables unwinding and this means leaking memory, not closing file descriptors, not unlocking mutexes and not rolling back database transactions on panic. It's fine for some applications to leave this to the operating system on process exit but I would argue that the default unwinding behavior is better for typical userspace applications.
    - ninkendo 2y ago
      All the things you describe are done automatically on program exit, even if the program is SIGKILL’ed. The kernel cleans up file descriptors, database transactions are rolled back automatically when the client disconnects (which it should be observed to be when the program exits and the kernel closes the connection as part of cleanup), and I’m not sure what you mean about mutexes, but if you mean in-memory ones, those don’t matter because the program is gone (if you mean like, file-based ones, those also should be implicitly unlocked by the kernel when the program exits, at least that’s how a good implementation is supposed to work, e.g. by writing the pid to the file or something.) The whole of modern operating systems are already very familiar with the idea of programs not being able to exit gracefully, and there’s already a well understood category of things that happen automatically even if your program crashes ungracefully. Whole systems are designed around this (databases issuing rollbacks when the client disconnects, being a perfect example.) The best thing to do is embrace this and never, ever rely on a Drop trait being executed for correctness. Always assume you could be SIGKILLed at any time (which you always can. Someone can issue a kill -9, or you could get OOM killed, etc.)
      - exDM69 2y ago
        I'm well aware of this and good that the option exists to bail out with abort instead. But there are still cases where you would like to fsync your mmaps, print out a warning message or just make sure your #[should_panic] negative tests don't trigger false positives in your tooling (like leak detectors or GPU validators) or abort the whole test run. It's not perfect by any means but it's better than potentially corrupting your data when a trivial assert fires or making negative tests spew warnings in ci runs. It's very easy to opt out from, and I don't consider the price of panic handlers and unwinding very expensive for most use cases.
wongarsu 2y ago
You can set panic: abort [1] if you don't want the unwinding mechanism. You still get a nice error message on panic, which causes the compiler to link in some formatting code from the standard library. I'm not sure if you can get rid of that. On the same page are also the options for controlling debug assertions and overflow checks, which would get rid of the "panics in debug, but not release", if that behavior bugs you 1: https://doc.rust-lang.org/cargo/reference/profiles.html#panic https://doc.rust-lang.org/cargo/reference/profiles.html#pani...
winstonewert 2y ago
Well, if they did that, then people could expect/demand stability with regard to what scenarios get the checks/panics optimized out. This would be a bit of a burden for the Rust maintainers. It would effectively make the optimizer part of the language specification, and that's undesireable.
goodpoint 2y ago
It's sad. If anything panics in the stdlib should be opt-in, not opt-out.

by XorNot 2y ago

dccsillag 2y ago

Yeah, I'm fairly sure that there is such a flag/toplevel attribute... and if there isn't, there should be one. It also feels like most of the pains on avoiding panics centers around allocations which, though a bit unfortunate, makes sense; it was an intentional design choice to make allocations panic instead of return Results, because most users of the language would probably crash on allocation fails anyways and it would introduce a lot of clutter. There was some effort some while ago on having better fallible allocations, but I'm not sure what happened over there.

dpc_01234 2y ago

https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html#unrecoverable-errors-with-panic https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-... ``` [profile.release] panic = 'abort' ```

rcxdude 2y ago
that just makes the panics unrecoverable. It doesn't statically guarantee no panics.
- lmm 2y ago
  It presumably avoids the linked in 300Kb that was supposedly part of the motivation for doing this though?
- wongarsu 2y ago
  There is no-panic [1] to turn panics in a function into compile errors, or the older no-panics-whatsoever [2] to do the same for the entire binary 1: https://crates.io/crates/no-panic https://crates.io/crates/no-panic 2: https://crates.io/crates/no-panics-whatsoever https://crates.io/crates/no-panics-whatsoever
  - themulticaster 2y ago
    no-panic uses link-time shenanigans to prevent panics in the compiled binary, but this isn't 100% reliable (as explained in the README, just pointing this out)
surajrmal 2y ago
After using rust for several years, I'm shocked this isn't the default. Making panics recoverable leads to them being used incorrectly.
- exDM69 2y ago
  Panics also unwind the stack and run all your Drop destructors. Setting `panic = abort` disables unwinding and this means leaking memory, not closing file descriptors, not unlocking mutexes and not rolling back database transactions on panic. It's fine for some applications to leave this to the operating system on process exit but I would argue that the default unwinding behavior is better for typical userspace applications.
  - ninkendo 2y ago
    All the things you describe are done automatically on program exit, even if the program is SIGKILL’ed. The kernel cleans up file descriptors, database transactions are rolled back automatically when the client disconnects (which it should be observed to be when the program exits and the kernel closes the connection as part of cleanup), and I’m not sure what you mean about mutexes, but if you mean in-memory ones, those don’t matter because the program is gone (if you mean like, file-based ones, those also should be implicitly unlocked by the kernel when the program exits, at least that’s how a good implementation is supposed to work, e.g. by writing the pid to the file or something.) The whole of modern operating systems are already very familiar with the idea of programs not being able to exit gracefully, and there’s already a well understood category of things that happen automatically even if your program crashes ungracefully. Whole systems are designed around this (databases issuing rollbacks when the client disconnects, being a perfect example.) The best thing to do is embrace this and never, ever rely on a Drop trait being executed for correctness. Always assume you could be SIGKILLed at any time (which you always can. Someone can issue a kill -9, or you could get OOM killed, etc.)
    - exDM69 2y ago
      I'm well aware of this and good that the option exists to bail out with abort instead. But there are still cases where you would like to fsync your mmaps, print out a warning message or just make sure your #[should_panic] negative tests don't trigger false positives in your tooling (like leak detectors or GPU validators) or abort the whole test run. It's not perfect by any means but it's better than potentially corrupting your data when a trivial assert fires or making negative tests spew warnings in ci runs. It's very easy to opt out from, and I don't consider the price of panic handlers and unwinding very expensive for most use cases.

wongarsu 2y ago

You can set panic: abort [1] if you don't want the unwinding mechanism. You still get a nice error message on panic, which causes the compiler to link in some formatting code from the standard library. I'm not sure if you can get rid of that. On the same page are also the options for controlling debug assertions and overflow checks, which would get rid of the "panics in debug, but not release", if that behavior bugs you 1: https://doc.rust-lang.org/cargo/reference/profiles.html#panic https://doc.rust-lang.org/cargo/reference/profiles.html#pani...

winstonewert 2y ago

Well, if they did that, then people could expect/demand stability with regard to what scenarios get the checks/panics optimized out. This would be a bit of a burden for the Rust maintainers. It would effectively make the optimizer part of the language specification, and that's undesireable.

goodpoint 2y ago

It's sad. If anything panics in the stdlib should be opt-in, not opt-out.