Stream: wg-ffi-unwind

Topic: lang team sync


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

@nikomatsakis I just submitted a PR with my write-up. (Do you mind this sort of dual-notification when you're already getting a GitHub notification for this?) https://github.com/nikomatsakis/project-ffi-unwind/pull/12/files

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

Please let me know if there's anything I'm not capturing that you think I should

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

To be clear, I am not expecting that this be merged prior to the meeting

nikomatsakis (Oct 17 2019 at 22:03, on Zulip):

I prefer zulip notification to GH

nikomatsakis (Oct 17 2019 at 22:04, on Zulip):

though I do try to keep up with both

Kyle Strand (Oct 17 2019 at 22:12, on Zulip):

Well then I shall continue to share!

Kyle Strand (Oct 17 2019 at 22:13, on Zulip):

FYI my other PR is now +7 instead of +95 lines

nikomatsakis (Oct 24 2019 at 18:44, on Zulip):

Hey @Kyle Strand -- did you plan to attend lang team meeting and/or have any concise summary? If not, I can prep one

Kyle Strand (Oct 24 2019 at 18:50, on Zulip):

I don't have a summary, but if you think it would be helpful I can join the meeting for a bit

Kyle Strand (Oct 24 2019 at 18:50, on Zulip):

(deleted)

Kyle Strand (Oct 24 2019 at 19:00, on Zulip):

@nikomatsakis Sorry to leave you in the lurch. Do you think it would be better to join or skip this week?

nikomatsakis (Oct 24 2019 at 20:40, on Zulip):

No worries -- but the team was fairly skeptical of this change to extern "C" permitting unwind by default

nikomatsakis (Oct 24 2019 at 20:40, on Zulip):

I took some notes and will try to update the document

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

OK, so, I have updated the document. To me, the argument for extern "C" making unwinding UB is pretty strong -- it comes down to better alignment between the default and reality (i.e., most FFI calls do not unwind, and so it's better to call out those that do, which means we can have more special treatment at less cost).

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

It seems to me that technical details (i.e., about what is or is not UB within LLVM) are largely orthogonal from the question of what our default should be -- we have to work them out either way, if we want "C unwind".

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

However, if we can't work them all out, then that is further argument for "C unwind"

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

So TL;DR at this point I feel pretty sure that "C" / "C unwind" is a better choice than "C" / "C noexcept"

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

I'd be curious @Amanieu / @gnzlbg if you see any problems with the arguments in the hackmd document.

gnzlbg (Oct 24 2019 at 21:13, on Zulip):

I’ll read that later, but “most FFI calls to C do not unwind” matches my experience as well

Kyle Strand (Oct 24 2019 at 21:26, on Zulip):

The reason I think the LLVM and other platform details are relevant is that I do think there's some value in matching existing behavior in the "native ecosystem"; and, in general, if unwinding can be expected to work safely in the ecosystem at large, then it seems reasonable to expect Rust to support that by default.

That said, I agree that this isn't the most important consideration, and that there are very good reasons why Rust already diverges substantially from C++ (the de facto "native ecosystem" trend setter)

Kyle Strand (Oct 24 2019 at 21:27, on Zulip):

For instance, conceptually, I like that mangling is explicitly controlled with no_mangle as opposed to implicit with extern "C"

Kyle Strand (Oct 24 2019 at 21:30, on Zulip):

But, as a data point for my "existing behavior in the ecosystem" comment, when I told nlewycky about the unwinding discussion, he was pretty surprised by the idea that Rust would try to "sandbox" unwinds

Kyle Strand (Oct 24 2019 at 21:31, on Zulip):

His position was that unwinding is part of the ABI, and the "C" ABI should be expected to potentially unwind (context: he was an LLVM dev for several years)

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

I think that's fair, but also abstract

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

In practice, a large number of C++ projects do not use exceptions (and compile with -fno-exceptions or whatever) -- in fact, I think maybe every C++ project I ever worked on? And of course things written in C largely do not unwind either. (Modulo longjmp I guess)

Kyle Strand (Oct 24 2019 at 21:57, on Zulip):

That's very on-brand for me :laughing:

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

( I actually don't know whether FF uses -fno-exceptions... I never really hacked on it that much:) )

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

In any case, the arguments in the doc are fairly specific

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

That said, I think one of them -- "code-size savings" -- is only mildly persuasive. I'd like to see realistic measurements of real projects.

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

On a more practical note, I feel like a "180" of this kind is itself going a bit "beyond our mandate" in this group -- I think if we really feel it's best, we should make the case, but it'll require broader exposure, since most of the community has been expecting the opposite default.

Kyle Strand (Oct 24 2019 at 22:04, on Zulip):

I'll think about it more (and hopefully have some time this weekend to write up summaries of all the discussion that's happened), but I think we can proceed with all of the following more or less in parallel:

[1] Centril brought this up in another thread as an argument against merging the remove-nounwind PR. Personally, despite the disagreements about abort-on-unwind-without-recourse in the past, I am currently of the opinion that it's okay to merge, because:

The main reason not to do this, I think, would be to keep open the possibility of changing the default. I would like to say that we could change it back to permit unwinding in the future as long as we say "the behavior is still not considered stable, but as of right now, in practice it aborts." But I'm not sure this is reasonable: people could rely on not-unwinding for safety, and then there is a risk of crates not adopting any explicit abort-on-unwind feature once we introduce it. I'm a bit torn on this question.

Amanieu (Oct 25 2019 at 01:49, on Zulip):

I'm a bit confused, is the plan to make "extern C" UB on unwind or abort on unwind?

Amanieu (Oct 25 2019 at 01:49, on Zulip):

In any case, I'm not too attached to allowing unwinding in "extern C" by default.

centril (Oct 25 2019 at 01:50, on Zulip):

Safe extern "C" fns must abort on unwind; otherwise you have unsoundness

Amanieu (Oct 25 2019 at 01:54, on Zulip):

@centril You are talking about extern "C" definitions, not declarations, right?

centril (Oct 25 2019 at 01:54, on Zulip):

yep

Amanieu (Oct 25 2019 at 01:54, on Zulip):

Right that clarifies things, thanks.

centril (Oct 25 2019 at 01:54, on Zulip):

not the thing in extern ABIString { ... } blocks (imports)

Kyle Strand (Oct 25 2019 at 02:09, on Zulip):

Sounds like everyone's in agreement that extern "C unwind" is an acceptable path forward, and that we are still leaning toward stabilizing the abort-logic for functions defined with extern "C". I hope to get some time this weekend to write up summaries of these discussions and maybe even get an RFC or two ready to post.

gnzlbg (Oct 25 2019 at 08:57, on Zulip):

@nikomatsakis i read the document, but i was confused in some passages because when the text says "C function" it is not clear to me whether that means extern "C" with or without unwinding allowed, `extern "C unwind", or in some cases, whether it means functions defined in Rust or function declarations.

gnzlbg (Oct 25 2019 at 08:58, on Zulip):

I'll leave some notes

Kyle Strand (Oct 31 2019 at 17:08, on Zulip):

@nikomatsakis I am pretty disheveled today so I'll join by audio :D

Kyle Strand (Oct 31 2019 at 17:09, on Zulip):

haven't written anything up yet, but my "summarizing discussions" file and the new PR itself might be sufficient anyway

Kyle Strand (Oct 31 2019 at 17:20, on Zulip):

Oh, also, project group sync today? Now that we are "announced" it might be good to put a link to the meeting somewhere easily-findable

gnzlbg (Oct 31 2019 at 19:36, on Zulip):

The sync went good

gnzlbg (Oct 31 2019 at 19:36, on Zulip):

For some reason muting my zoom didn't really mute it :/

gnzlbg (Oct 31 2019 at 19:36, on Zulip):

So thanks to whoever supermuted me

Last update: Nov 15 2019 at 09:40UTC