Stream: project-ffi-unwind

Topic: Revised RFC


view this post on Zulip BatmanAoD (Kyle Strand) (Apr 26 2020 at 19:48):

Okay, I've revised the RFC based on the comments and requested re-review from Niko.

I made one major change: I said we consider forced unwind across frames with destructors to be UB regardless of platform or ABI spec. The rationale is in the comments and the updated text.

view this post on Zulip nikomatsakis (Apr 27 2020 at 14:48):

@BatmanAoD (Kyle Strand) nice! will review

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 29 2020 at 16:39):

@Amanieu @nikomatsakis Do either of you have any issues I can try to address before we sync tomorrow?

view this post on Zulip nikomatsakis (Apr 29 2020 at 17:27):

let me review

view this post on Zulip nikomatsakis (Apr 29 2020 at 17:50):

left some thoughts

view this post on Zulip Amanieu (Apr 29 2020 at 23:21):

I'm generally not a fan of the term "forced unwinding" and all the complications around it.

view this post on Zulip Amanieu (Apr 29 2020 at 23:22):

It is a concept that is originally from the Itanium ABI, and which we extended to include Windows' longjmp as well.

view this post on Zulip Amanieu (Apr 29 2020 at 23:23):

I feel that it would be clearer if we instead talked in terms of the source of the unwind.

view this post on Zulip Amanieu (Apr 29 2020 at 23:25):

So first we describe the behavior of unwinding caused by Rust panics only. And how that interacts with extern "C", extern "Rust" and extern "C unwind" under panic=abort and panic=unwind. This includes describing how such a panic behaves when unwinding through foreign code ("just like a C++ exception").

view this post on Zulip Amanieu (Apr 29 2020 at 23:27):

The base rule is that foreign unwinding (which we define as "returning to the parent frame without returning from a function normally") is UB by default unless specifically allowed in this RFC.

view this post on Zulip Amanieu (Apr 29 2020 at 23:32):

Then we list the exceptions:

view this post on Zulip Amanieu (Apr 29 2020 at 23:33):

Notice how there is no mention of "forced unwinding". Just rules for the different types of unwinding. And everything else is UB by default.

view this post on Zulip Amanieu (Apr 29 2020 at 23:33):

(I was a bit more liberal in the rules than what we originally agreed with, but it's just to show an example).

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 00:11):

Hm. I may be biased by the sunk cost of having written a draft already, but I don't see why that approach would be better.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 00:14):

Though admittedly the existing draft does not acknowledge different unwind mechanisms, and I'm not sure what it needs to say about them.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 00:17):

I also don't think we should promise correct behavior when unwinding over destructors with longjmp on Windows.

view this post on Zulip nikomatsakis (Apr 30 2020 at 14:49):

hmm, I don't know, I think I agree with @Amanieu -- that seems similar to what I was saying about identifying scenarios --

view this post on Zulip nikomatsakis (Apr 30 2020 at 14:49):

I think if I were coming to the RFC I would want to be able to "pattern match" the thing I am trying to do and get some idea of the rules around it

view this post on Zulip nikomatsakis (Apr 30 2020 at 14:50):

I don't have a strong opinion about "forced unwind" vs other things, but there's definitely precedent for citing "longjmp" vs that category (I think that's what C++ does...?)

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:16):

nikomatsakis said:

hmm, I don't know, I think I agree with Amanieu -- that seems similar to what I was saying about identifying scenarios --

that said

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:16):

I think that what this suggestion could also be 'encoded' into the detailed rule section


Last updated: Jan 26 2022 at 09:02 UTC