Stream: project-ffi-unwind

Topic: lang team sync


view this post on Zulip BatmanAoD (Kyle Strand) (Oct 17 2019 at 18:50):

@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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 17 2019 at 18:50):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 17 2019 at 19:01):

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

view this post on Zulip nikomatsakis (Oct 17 2019 at 22:03):

I prefer zulip notification to GH

view this post on Zulip nikomatsakis (Oct 17 2019 at 22:04):

though I do try to keep up with both

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 17 2019 at 22:12):

Well then I shall continue to share!

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 17 2019 at 22:13):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 18:44):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 18:50):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 18:50):

(deleted)

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 19:00):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 20:40):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 20:40):

I took some notes and will try to update the document

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:08):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:08):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:08):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:08):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:09):

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

view this post on Zulip gnzlbg (Oct 24 2019 at 21:13):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 21:26):

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)

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 21:27):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 21:30):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 21:31):

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)

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:56):

I think that's fair, but also abstract

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:57):

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)

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 21:57):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:57):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:57):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:58):

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

view this post on Zulip nikomatsakis (Oct 24 2019 at 21:59):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 24 2019 at 22:04):

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.

view this post on Zulip Amanieu (Oct 25 2019 at 01:49):

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

view this post on Zulip Amanieu (Oct 25 2019 at 01:49):

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

view this post on Zulip centril (Oct 25 2019 at 01:50):

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

view this post on Zulip Amanieu (Oct 25 2019 at 01:54):

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

view this post on Zulip centril (Oct 25 2019 at 01:54):

yep

view this post on Zulip Amanieu (Oct 25 2019 at 01:54):

Right that clarifies things, thanks.

view this post on Zulip centril (Oct 25 2019 at 01:54):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 25 2019 at 02:09):

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.

view this post on Zulip gnzlbg (Oct 25 2019 at 08:57):

@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.

view this post on Zulip gnzlbg (Oct 25 2019 at 08:58):

I'll leave some notes

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 17:08):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 17:09):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 17:20):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 19:36):

The sync went good

view this post on Zulip gnzlbg (Oct 31 2019 at 19:36):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 19:36):

So thanks to whoever supermuted me


Last updated: Jan 26 2022 at 08:21 UTC