Add support for a no-unwind compiler flag

[Gankro]

This would reinterpret all panics as aborts. This has the potential to reduce compilation time, reduce binary size, improve runtime performance, and increase programmer reasoning capacity (an unwind can't smash through this careful unsafe code).

The precise technical details are a bit hairy, though. All libraries/binaries involved would likely need to have the same setting for this flag, which would imply two std builds per platform. Presumably Cargo will need to support metadata for unwind/no-unwind compatibility of the codebase.

Regardless there seems to be a lot of support for doing this eventually, so here's a formal issue to track this. Maybe someone will be brave enough to write a proper RFC.

[mahkoh]

👍

[mitsuhiko]

Huge plus one for me. I wanted to propose the same already but I believe we need to find a good way to make rust code less panic'y. I will volunteer for bringing up an RFC in any case once I feel confident we have a good plan for error handling.

[bstrie]

For distributing libraries as source, I can easily see cargo handling whether or not to enable unwinding. For distributing libraries as binaries, perhaps we could look into distributing fat binaries with both versions compiled in.

[mahkoh]

IIRC @pcwalton has been planing to write this RFC for some time.

[Gankro]

CC @thestinger

[bstrie]

Note that the question of whether the flag should be enabled by default can be deferred to later, what's most important here is getting the flag in the first place.

[Valloric]

Huge +1 from me as well. Lots of people/projects/companies turn off exception support in C++ (with -fno-exceptions or its equivalent) for the sake of performance. Nobody is screaming that "C++ is being forked" because that option exists.

This is one of those features that rustc will without a doubt have sooner or later. It's just inevitable; if rustc won't have it officially, we'll see unofficial forks that provide this (and probably more than one). This feature is that necessary.

[vadimcn]

A hypothetical question: if instead of unwinding stack and executing handlers at each frame, we linked all objects with destructors into a list (per-thread), would people feel better about panics?
I mean, unlike C++, in case of panic Rust could traverse this list and free resources, then dump the stack without unwinding it. This approach would have some runtime cost in the non-failure case (to link and unlink objects), but would avoid generating landing pads and stack unwind info.

[pcwalton]

That would be quite a bit more expensive than the scheme we have today. I think that people are exaggerating the cost of the unwinding scheme we have today: I'm not opposed to allowing it to be turned off, but I think the cost of the unwinding info is exaggerated a lot. "Zero-cost exception handling" is a bit of a lie, but it's not far from the truth.

[vadimcn]

Well, I would concede the point to unwind-haters that currently landing pads look pretty bad. It's basically a second copy of all the scope exit code, that unfortunately cannot be shared with the "normal" control flow. To add insult to the injury, I've seen LLVM inlining drop glue into the landing pads :(
C++ exception semantics provide a way to resume execution of a stack frame after catch(), but Rust doesn't need that; it merely needs to execute destructors, which don't care which stack frame they were called from. So there's got to be something we can optimize here...

[thestinger]

I don't think any language or (public) library-level changes are required. It's just a compiler optimization and doesn't need an RFC. I filed an issue about this a while ago: rust-lang/rust#18511

[thestinger]

@pcwalton: It hamstring's our ability to optimize library code along and does hurt LLVM's ability to perform transformations on the code by adding lots of flow control it has to preserve. It also makes it much harder to write correct unsafe code to the point where I think most memory safety problems in the libraries are going to be caused by this.

[pcwalton]

This isn't the place to argue whether Rust should or should not support unwinding. We're all in agreement that unwinding should not be mandatory.

[thestinger]

If you don't want an argument, don't claim that the other side is exaggerating the costs.

[pcwalton]

My comment was in reference to "if instead of unwinding stack and executing handlers at each frame, we linked all objects with destructors into a list (per-thread), would people feel better about panics?" This would have enormous overhead relative to unwinding and the fact that it's being brought up shows that the costs of unwinding are being exaggerated in some people's minds.

[ticki]

What is the state of this?

[nagisa]

We have -C no-landing-pads, which essentially is what’s being proposed here. Panic still unwinds, but that mostly results in something resembling an abort because there’s no handlers/cleanups anywhere on the user stack.

[ticki]

@nagisa I thought that that didn't affect dependencies?

[nagisa]

@ticki you cannot affect dependencies whose code is already generated anyway, can you? i.e. implementing that sort of feature would require some runtime panic impl switching.

[Stebalien]

Triage: Fixed by #1513