Stream: wg-ffi-unwind

Topic: WG scope


Kyle Strand (Oct 17 2019 at 19:45, on Zulip):

The harm I see is that the WG won't end up fulfilling its goal of offering a way to interface with the platform ABI

@gnzlbg I think this statement makes "interface" sound like a bit more of an all-or-nothing proposition than it is. "Propagating" (without catching) is one way of "interfacing" with the exception ABI.

Kyle Strand (Oct 17 2019 at 19:47, on Zulip):

Also, I think we need to be very cautious about making assumptions about what "supporting the ABI" entails (even for a fairly comprehensive definition of "supporting") without limiting those assumptions to specific platforms. In particular, for any goals that this WG adopts because they seem desirable and achievable for the Itanium ABI, we need to be careful not to automatically commit ourselves to supporting the same feature on Windows.

gnzlbg (Oct 17 2019 at 19:47, on Zulip):

I don't think we should treat it as all or nothing, but on some major platforms, native system software pretty much uses all of the ABI

gnzlbg (Oct 17 2019 at 19:47, on Zulip):

so if we want to be able to properly interface with such software from Rust, then we'd need to support whatever parts of the ABI such software requires

Kyle Strand (Oct 17 2019 at 19:48, on Zulip):

That's reasonable. Josh Triplett is correct that _catching_ foreign exceptions was not originally in scope for this WG, though.

Kyle Strand (Oct 17 2019 at 19:48, on Zulip):

It definitely seems like a natural extension of the charter

Kyle Strand (Oct 17 2019 at 19:48, on Zulip):

but it is not something I think we can _currently_ commit to solving.

gnzlbg (Oct 17 2019 at 19:48, on Zulip):

lso, I think we need to be very cautious about making assumptions about what "supporting the ABI" entails (even for a fairly comprehensive definition of "supporting") without limiting those assumptions to specific platforms.

That's a good point.

gnzlbg (Oct 17 2019 at 19:49, on Zulip):

I've been wondering these last days if it wouldn't be better to just expose platform ABIs instead of a generic "C unwind" ABI

gnzlbg (Oct 17 2019 at 19:49, on Zulip):

But I think that could be always done later

gnzlbg (Oct 17 2019 at 19:49, on Zulip):

e.g. adding "C unwind" now does not prevent adding "Itanium" or "SEH" later

Kyle Strand (Oct 17 2019 at 19:49, on Zulip):

For cases where interactions with foreign exceptions are necessary, platform-specific features may indeed be a good approach!

Kyle Strand (Oct 17 2019 at 19:50, on Zulip):

I do think that "C unwind", without any support for interacting with exception objects, solves enough real-world use cases to be valuable on its own

gnzlbg (Oct 17 2019 at 19:50, on Zulip):

But all of the unwindings that we end up supporting, might end up interacting with Rust frames at some point, and therefore with catch_unwind in those frames

gnzlbg (Oct 17 2019 at 19:52, on Zulip):

I do think that "C unwind", without any support for interacting with exception objects, solves enough real-world use cases to be valuable on its own

Yes, I think so. I guess that my view is that if it were to support foreign exceptions, it would solve the majority of cases, leaving no room below for other language features.

Kyle Strand (Oct 17 2019 at 19:52, on Zulip):

unwindings ...might end up interacting...with catch_unwind

I think that it's okay to leave that undefined (possibly indefinitely), though. Do you think that would be specifically "more wrong" than, e.g., leaving it undefined behavior to longjmp over frames with Drop objects?

nikomatsakis (Oct 24 2019 at 21:11, on Zulip):

But I think that could be always done later

I think this could be done later and I also think Rust has a strong commitment to making cross-platform portability work and work well. I think that applies here. You should be able to do "basic stuff" portably, the concepts are very similar.

Last update: Nov 15 2019 at 10:55UTC