Stream: project-ffi-unwind

Topic: Revised RFC


BatmanAoD (Kyle Strand) (Apr 26 2020 at 19:48, on Zulip):

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.

nikomatsakis (Apr 27 2020 at 14:48, on Zulip):

@BatmanAoD (Kyle Strand) nice! will review

BatmanAoD (Kyle Strand) (Apr 29 2020 at 16:39, on Zulip):

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

nikomatsakis (Apr 29 2020 at 17:27, on Zulip):

let me review

nikomatsakis (Apr 29 2020 at 17:50, on Zulip):

left some thoughts

Amanieu (Apr 29 2020 at 23:21, on Zulip):

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

Amanieu (Apr 29 2020 at 23:22, on Zulip):

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

Amanieu (Apr 29 2020 at 23:23, on Zulip):

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

Amanieu (Apr 29 2020 at 23:25, on Zulip):

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").

Amanieu (Apr 29 2020 at 23:27, on Zulip):

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.

Amanieu (Apr 29 2020 at 23:32, on Zulip):

Then we list the exceptions:

Amanieu (Apr 29 2020 at 23:33, on Zulip):

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

Amanieu (Apr 29 2020 at 23:33, on Zulip):

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

BatmanAoD (Kyle Strand) (Apr 30 2020 at 00:11, on Zulip):

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.

BatmanAoD (Kyle Strand) (Apr 30 2020 at 00:14, on Zulip):

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

BatmanAoD (Kyle Strand) (Apr 30 2020 at 00:17, on Zulip):

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

nikomatsakis (Apr 30 2020 at 14:49, on Zulip):

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

nikomatsakis (Apr 30 2020 at 14:49, on Zulip):

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

nikomatsakis (Apr 30 2020 at 14:50, on Zulip):

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...?)

nikomatsakis (Apr 30 2020 at 17:16, on Zulip):

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

nikomatsakis (Apr 30 2020 at 17:16, on Zulip):

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

Last update: Jun 05 2020 at 22:30UTC