Stream: project-ffi-unwind

Topic: weekly meeting


nikomatsakis (Oct 31 2019 at 17:36, on Zulip):

Hey @WG-ffi-unwind -- are we going to have a sync this week?

nikomatsakis (Oct 31 2019 at 17:38, on Zulip):

er, I see @Kyle Strand you wrote a few comments in the "lang team sync" topic...

nikomatsakis (Oct 31 2019 at 17:38, on Zulip):

let's use this one for weekly meetings instead? seems like a better name :)

nikomatsakis (Oct 31 2019 at 17:38, on Zulip):

so where are we at

nikomatsakis (Oct 31 2019 at 17:39, on Zulip):

I guess @Kyle Strand I should just merge https://github.com/rust-lang/project-ffi-unwind/pull/16 ?

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

Sounds good!

nikomatsakis (Oct 31 2019 at 17:42, on Zulip):

I think this is basically the same content as https://github.com/rust-lang/rfcs/pull/2797, right?

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

I feel like the PR is close to having agreement, which is nice (I am guessing Centril is holding off on approving until the scope questions are addressed)

nikomatsakis (Oct 31 2019 at 17:42, on Zulip):

I haven't revisited since my last round of comments

nikomatsakis (Oct 31 2019 at 17:42, on Zulip):

did you modify the text at all in response to those?

nikomatsakis (Oct 31 2019 at 17:42, on Zulip):

I should check

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

I guess Kyle Strand I should just merge https://github.com/rust-lang/project-ffi-unwind/pull/16 ?

You should always merge my PRs :wink:

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

No, I haven't made any modifications since then

nikomatsakis (Oct 31 2019 at 17:43, on Zulip):

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

@Kyle Strand which "summarizing discussions" file did you mean? oh, the one that summarized all of zulip?

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

But those were the only two outstanding concerns

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

yep

nikomatsakis (Oct 31 2019 at 17:43, on Zulip):

ok, I feel like there was some discussion I thought would be good to summarize specifically..not sure which it was now :)

nikomatsakis (Oct 31 2019 at 17:44, on Zulip):

"catching foreign exceptions", that topic

nikomatsakis (Oct 31 2019 at 17:44, on Zulip):

I guess the other lang team update is that we've extended the set of arguments somewhat around "C unwind" vs "C noexcept" etc

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

Yes

nikomatsakis (Oct 31 2019 at 17:46, on Zulip):

oh I see there have been some new additions as well

nikomatsakis (Oct 31 2019 at 17:46, on Zulip):

I have to read those and see if I find them persuasive

nikomatsakis (Oct 31 2019 at 17:46, on Zulip):

one thing I would like to have is a list of which functions use "C" but actually can unwind

nikomatsakis (Oct 31 2019 at 17:47, on Zulip):

I guess longjmp is such an example :)

nikomatsakis (Oct 31 2019 at 17:47, on Zulip):

(at least on MSVC)

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

I have to read those and see if I find them persuasive

FWIW I believe the HackMD updates capture the important bits of the conversation; reading the whole thread is likely not an optimal use of time

nikomatsakis (Oct 31 2019 at 17:48, on Zulip):

I do not mean to read any threads :)

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

Perfect!

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

which thread are you referring to, "noexcept-like feature"? :)

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

Adding the guarantee to the language that extern "C" do not unwind has the same expressive power as C++ noexcept keyword, but much worse ergonomics.

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

Yes

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

I am struggling with this statement :)

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

in particular, I'd lke to see examples of the ergonomics?

acfoltzer (Oct 31 2019 at 17:49, on Zulip):

hey, sorry I'm late. catching up now

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

maybe they're below, but I got lost in the proof..

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

Oh, for that it might actually be useful to look at the examples gnzlbg gave in the thread

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

https://rust-lang.zulipchat.com/#narrow/stream/210922-wg-ffi-unwind/topic/noexcept-like.20feature/near/179520449

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

and

https://rust-lang.zulipchat.com/#narrow/stream/210922-wg-ffi-unwind/topic/noexcept-like.20feature/near/179444817

nikomatsakis (Oct 31 2019 at 17:50, on Zulip):

okI think the argument is:

nikomatsakis (Oct 31 2019 at 17:51, on Zulip):

you might like to guarantee "no unwinding" in cases where no C code is involved

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

Yes

nikomatsakis (Oct 31 2019 at 17:51, on Zulip):

that's an interesting argument

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

and the idea is that introducing this feature "accidentally" by way of ABI strings would be detrimental

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

"detrimental" may be too strong

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

Generally, I do think that if/when we introduce a feature to cause functions to automatically abort-on-panic, it should be applicable to functions regardless of the ABI

acfoltzer (Oct 31 2019 at 17:54, on Zulip):

okay, caught up on this thread at least. I have had even less time than I was expecting given our current demo crunch. I'm excited by #16!

nikomatsakis (Oct 31 2019 at 17:54, on Zulip):

That seems true but it doesn't mean we can't also the ABI

nikomatsakis (Oct 31 2019 at 17:55, on Zulip):

but I see the point

nikomatsakis (Oct 31 2019 at 17:55, on Zulip):

I've summarized here:

You might like to avoid unwinding of Rust functions, too

We discussed how unsafe code in particular must be careful to be "unwind safe", but this applies not just to "C" functions but really to any Rust function. Therefore, we might like to have a feature that guarantees that some callee cannot unwind. But do we really want to use the ABI string to contrl this in the more general case?

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

I think the quote from Nick L that I added to the HackMD doc captures the concern: "FFI is not a sandbox"

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

which is to say, the lang team has been planning to make it a sandbox for a long time, but at least one LLVM dev thought that sounded like the wrong approach. Not sure what weight to assign that fact.

acfoltzer (Oct 31 2019 at 17:57, on Zulip):

sandbox in what sense, here?

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

Sandboxing unwinding ops to prevent them from escaping

nikomatsakis (Oct 31 2019 at 17:57, on Zulip):

I mean it doesn't actually "prevent", of course, since it would be "UB"

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

by changing the semantics of a function (i.e. inserting a shim that does something)

nikomatsakis (Oct 31 2019 at 17:57, on Zulip):

I think it's more accurate to say that the ABI is promising not to unwind

nikomatsakis (Oct 31 2019 at 17:57, on Zulip):

it is most definitely not sandboxing it

nikomatsakis (Oct 31 2019 at 17:58, on Zulip):

it doesn't seem that different frm any other type

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

Oh, there's a misunderstanding here. The "sandbox" concern is about the planned behavior of extern "C", which is to insert an abort-on-unwind shim (which is well defined)

acfoltzer (Oct 31 2019 at 17:58, on Zulip):

got it. yeah, seems like the best we can do is insert shims for the unwinding mechanisms we're aware of, but that's certainly not a guarantee

nikomatsakis (Oct 31 2019 at 17:59, on Zulip):

Oh, there's a misunderstanding here. The "sandbox" concern is about the planned behavior of extern "C", which is to insert an abort-on-unwind shim (which is well defined)

that is only true for

extern "C" fn foo() { }

but not calls to some random extern "C" fn

nikomatsakis (Oct 31 2019 at 17:59, on Zulip):

it seems like a key point

nikomatsakis (Oct 31 2019 at 17:59, on Zulip):

because the strongest argument against extern "C" unwinding has precisely to do with this

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

True.

nikomatsakis (Oct 31 2019 at 17:59, on Zulip):

at least what I see as the strongest argument

Kyle Strand (Oct 31 2019 at 18:00, on Zulip):

Hm....I would see that as an argument for extern "C" unwinding: since the abort-shim can only be inserted in Rust functions, that would make extern "C" inconsistent.

nikomatsakis (Oct 31 2019 at 18:00, on Zulip):

which is that -Cpanic=abort must either introduce shims on calls to extern "C" functions to abort or else it means that -Cpanic=abort can cause UB

nikomatsakis (Oct 31 2019 at 18:00, on Zulip):

for code that otherwise worked

nikomatsakis (Oct 31 2019 at 18:00, on Zulip):

and then there is the question of the cost of said shims in terms of code size (I am not sure what the answer is there)

Kyle Strand (Oct 31 2019 at 18:00, on Zulip):

I'm talking about the non-panic=abort case, i.e., the behavior originally introduced in 1.24.0

acfoltzer (Oct 31 2019 at 18:01, on Zulip):

those shims might also depend on platform/library calls that are exactly the kinds of things that, say, embedded would want to avoid

nikomatsakis (Oct 31 2019 at 18:01, on Zulip):

Hm....I would see that as an argument for extern "C" unwinding: since the abort-shim can only be inserted in Rust functions, that would make extern "C" inconsistent.

fair, although you could view that as just an argument against adding the shims (to avoid inconsistency)

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

those shims might also depend on platform/library calls that are exactly the kinds of things that, say, embedded would want to avoid

I suppose that if you are on a platform that has no unwinding mechanism, then that's a different scenario

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

(not sure if that's what you were implying)

Kyle Strand (Oct 31 2019 at 18:02, on Zulip):

Right -- without the shims, extern "C" would unwind

Kyle Strand (Oct 31 2019 at 18:02, on Zulip):

instead of aborting

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

the point is that throws of foreign exceptions are out of our control, ultimately, so -Cpanic=abort can't change them to aborts

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

Right -- without the shims, extern "C" would unwind

it would just be UB al the time

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

(presuming we added "C unwind", I mean)

Kyle Strand (Oct 31 2019 at 18:03, on Zulip):

Re: panic=abort and calling foreign functions that unwind, I'd like to know whether noexcept in LLVM actually causes undefined behavior there. E.g. we already know it doesn't interfere with longjmp on Windows

nikomatsakis (Oct 31 2019 at 18:04, on Zulip):

@gnzlbg are you around?

acfoltzer (Oct 31 2019 at 18:04, on Zulip):

I don't like appealing to the authority of the C/C++ world, but if my -fno-exceptions code called a function in a library that threw an exception, I wouldn't expect anything other than UB

gnzlbg (Oct 31 2019 at 18:04, on Zulip):

@nikomatsakis more or less

nikomatsakis (Oct 31 2019 at 18:04, on Zulip):

@acfoltzer yeah but that's the scenario I think we're trying to avoid

Kyle Strand (Oct 31 2019 at 18:04, on Zulip):

That's certainly my default assumption in that world :laughing:

nikomatsakis (Oct 31 2019 at 18:04, on Zulip):

that is an alternative though

gnzlbg (Oct 31 2019 at 18:05, on Zulip):

I haven't read this thread

nikomatsakis (Oct 31 2019 at 18:05, on Zulip):

@gnzlbg what I specifically wanted to ask you is

nikomatsakis (Oct 31 2019 at 18:05, on Zulip):

do you have a list somewhere of libc functions that might unwind?

gnzlbg (Oct 31 2019 at 18:05, on Zulip):

yes, I posted it on the other thread, wait a sec

nikomatsakis (Oct 31 2019 at 18:05, on Zulip):

is it like "any pthread function", in the case of cancelation occuring?

nikomatsakis (Oct 31 2019 at 18:05, on Zulip):

aah, sorry

gnzlbg (Oct 31 2019 at 18:06, on Zulip):

http://man7.org/linux/man-pages/man7/pthreads.7.html

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

I don't like appealing to the authority of the C/C++ world, but if my -fno-exceptions code called a function in a library that threw an exception, I wouldn't expect anything other than UB

to expand on this -- the question is basically whether -Cpanic=abort should be the kind of thing that users have to be very careful and knowledge about (like certain details of target-feature), or is it something you can enable casually?

gnzlbg (Oct 31 2019 at 18:06, on Zulip):

s it like "any pthread function", in the case of cancelation occuring?

No, its more like any C or POSIX API that can do a system call

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

@gnzlbg presumably longjmp also falls into this category?

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

No, its more like any C or POSIX API that can do a system call

woah wait hold up :)

gnzlbg (Oct 31 2019 at 18:06, on Zulip):

in that link go for cancellation points, and there is a huge list: poll, open, sleep,

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

that's a fairly broad category

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

ok, that's interesting

gnzlbg (Oct 31 2019 at 18:07, on Zulip):

yes, there are a lot of APIs that are required to be cancellation points, and many that are allowed to be

gnzlbg (Oct 31 2019 at 18:07, on Zulip):

e.g. printf can be a cancellation point

gnzlbg (Oct 31 2019 at 18:07, on Zulip):

basically it works like a garbage collector would in say Java

gnzlbg (Oct 31 2019 at 18:08, on Zulip):

when you cancel a thread, the threading run-time will do so, once that thread calls a function from the C run-time

gnzlbg (Oct 31 2019 at 18:08, on Zulip):

if a thread doesn't do that, the run-time has little options to cancel the thread because the thread is doing other stuff

gnzlbg (Oct 31 2019 at 18:08, on Zulip):

so by calling open, you are yielding to the run-time, and might do a context switch, and at that point the runtime might say "you are cancelled"

acfoltzer (Oct 31 2019 at 18:09, on Zulip):

that makes a lot of sense but the implications are kind of horrifying

gnzlbg (Oct 31 2019 at 18:10, on Zulip):

I mean, the "anything that can do a context switch is a cancellation point" is my rule of thumb

gnzlbg (Oct 31 2019 at 18:10, on Zulip):

There are like ~50 or so POSIX APIs that can be cancellation points

gnzlbg (Oct 31 2019 at 18:10, on Zulip):

there are many C APIs that are not. Those 50 APIs are used a lot though.

gnzlbg (Oct 31 2019 at 18:11, on Zulip):

Then there is the issue of what happens if the thread doesn't call a cancellation point for too long

centril (Oct 31 2019 at 18:11, on Zulip):

I feel like the PR is close to having agreement, which is nice (I am guessing Centril is holding off on approving until the scope questions are addressed)

@Kyle Strand I checked my box 2 days ago but it seems rfcbot didn't record it

nikomatsakis (Oct 31 2019 at 18:11, on Zulip):

@gnzlbg thanks I will add those details to the hackmd

nikomatsakis (Oct 31 2019 at 18:11, on Zulip):

so I think i've revised my opinion

nikomatsakis (Oct 31 2019 at 18:11, on Zulip):

I used to think this was open-and-shut

centril (Oct 31 2019 at 18:11, on Zulip):

There; the "RFC" is in FCP now

nikomatsakis (Oct 31 2019 at 18:12, on Zulip):

but now I think that it's unclear

gnzlbg (Oct 31 2019 at 18:12, on Zulip):

there is the question whether we want to support those cancellation points

nikomatsakis (Oct 31 2019 at 18:13, on Zulip):

yes

gnzlbg (Oct 31 2019 at 18:13, on Zulip):

for example, we could say that using pthread_cancel with libstd threads is UB

gnzlbg (Oct 31 2019 at 18:13, on Zulip):

that's kind of the status quo right now

nikomatsakis (Oct 31 2019 at 18:13, on Zulip):

I also used to think that "C noexcept" was a "no brainer" to include, but now I think that is less clear -- the idea of just having "C" (which suppors unwinding in the platform default way) is somewhat appealing, and maybe having some form of no-except that is orthogonal to ABI

nikomatsakis (Oct 31 2019 at 18:13, on Zulip):

right, I think that is one of the options

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

I mean I think pthread cancelation is a terrible ida anyway :)

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

but .. maybe that's not for me to decide

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

I at least didn't appreciate that unwinding was used in this way

Kyle Strand (Oct 31 2019 at 18:14, on Zulip):

I also used to think that "C noexcept" was a "no brainer" to include, but now I think that is less clear -- the idea of just having "C" (which suppors unwinding in the platform default way) is somewhat appealing, and maybe having some form of no-except that is orthogonal to ABI

Yes, I don't believe it's a "no brainer" either :smile:

gnzlbg (Oct 31 2019 at 18:14, on Zulip):

might be a libs-team issue

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

I feel like it merits a more focused discussion

centril (Oct 31 2019 at 18:14, on Zulip):

but .. maybe that's not for me to decide

@nikomatsakis general point: I think it's fine to have opinionated language design

gnzlbg (Oct 31 2019 at 18:14, on Zulip):

note that if a thread doesn't call a C run-time function for a while, the run-time might send a signal and just kill it

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

one thing that I think would be highly relevant would be data

centril (Oct 31 2019 at 18:14, on Zulip):

(As an also-Haskeller it is predictable for me to say that however)

nikomatsakis (Oct 31 2019 at 18:15, on Zulip):

I would be interestd -- since @Taylor Cramer cares a lot about this -- to gather data on fuschia builds without -Cpanic=abort, for example

nikomatsakis (Oct 31 2019 at 18:15, on Zulip):

which is kind of a "worse case' :)

nikomatsakis (Oct 31 2019 at 18:16, on Zulip):

might be a libs-team issue

actually it occurs to me that

nikomatsakis (Oct 31 2019 at 18:16, on Zulip):

this is also an argument for #[unwind(allow)]

nikomatsakis (Oct 31 2019 at 18:16, on Zulip):

i.e., if we say that "C" ABI permits unwinding, but the function must be declared to unwind, and by-pointer calls assume it may unwind

centril (Oct 31 2019 at 18:16, on Zulip):

@nikomatsakis huh?

nikomatsakis (Oct 31 2019 at 18:17, on Zulip):

then the libc functions can become #[unwind(allow)]

nikomatsakis (Oct 31 2019 at 18:17, on Zulip):

in a backwards compatible way

gnzlbg (Oct 31 2019 at 18:17, on Zulip):

yes, that was also another possible design

centril (Oct 31 2019 at 18:17, on Zulip):

libc's backwards compatibility policies are not something I care about

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

Niko, do you mean that without the unwind(allow) annotation, extern "C" fn ... { /* Rust code */ } would insert the abort-shim?

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

libc's backwards compatibility policies are not something I care about

Noted, but that's not universal!

nikomatsakis (Oct 31 2019 at 18:18, on Zulip):

yes but also

nikomatsakis (Oct 31 2019 at 18:18, on Zulip):

it's not just about libc back-compat

Kyle Strand (Oct 31 2019 at 18:19, on Zulip):

Centril, I believe you previously objected to extern "C" <Rust fn> inserting the shim, but extern "C" being assumed to "possibly unwind", being inconsistent?

nikomatsakis (Oct 31 2019 at 18:19, on Zulip):

I guess it's a variant of the "it's simpler to have one ABI that supports the things the ABI supports"

centril (Oct 31 2019 at 18:19, on Zulip):

@nikomatsakis btw, 10 min to pre-triage

nikomatsakis (Oct 31 2019 at 18:19, on Zulip):

i.e., all extern "C" functions can unwind (the ABI permits it) -- but if we know the callee, we may know they won't

nikomatsakis (Oct 31 2019 at 18:19, on Zulip):

you could also argue for the opposite default

nikomatsakis (Oct 31 2019 at 18:20, on Zulip):

which is where @Amanieu started

nikomatsakis (Oct 31 2019 at 18:20, on Zulip):

ok, I'm seeing the case for that a bit stronger

nikomatsakis (Oct 31 2019 at 18:21, on Zulip):

I want to spend some time thinking on how to re-organize the hackmd now to better bring these ideas out

centril (Oct 31 2019 at 18:22, on Zulip):

@Kyle Strand "the shim" ?

centril (Oct 31 2019 at 18:22, on Zulip):

the abort on unwind shim?

centril (Oct 31 2019 at 18:22, on Zulip):

or some other?

centril (Oct 31 2019 at 18:22, on Zulip):

That sentence wasn't clear enough for me to understand & answer

Kyle Strand (Oct 31 2019 at 18:23, on Zulip):

Sorry, yes, the abort-on-unwind shim.

centril (Oct 31 2019 at 18:23, on Zulip):

@nikomatsakis From a purely compiler & spec POV I think a distinct ABI string is simplest at least; it is using an existing infra rather than inventing a new one

centril (Oct 31 2019 at 18:24, on Zulip):

@Kyle Strand the abort-on-unwind shim is mandatory if unwinding is not allowed for soundness

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

nikomatsakis From a purely compiler & spec POV I think a distinct ABI string is simplest at least; it is using an existing infra rather than inventing a new one

Removing nounwind from LLVM code generation for extern "C", and stabilizing the unwind(allowed/abort) attributes, is even simpler, isn't it?

centril (Oct 31 2019 at 18:25, on Zulip):

I don't believe so

nikomatsakis (Oct 31 2019 at 18:26, on Zulip):

@centril when you invoke a function, we already have a unique type that represents known callees

centril (Oct 31 2019 at 18:26, on Zulip):

The "Rust" ABI already does switch nounwind off, so that logic already exists wrt. pattern matching on ABIs

nikomatsakis (Oct 31 2019 at 18:26, on Zulip):

so it's not hard to distinguish "call by pointer" from "call to known function"

Kyle Strand (Oct 31 2019 at 18:26, on Zulip):

Kyle Strand the abort-on-unwind shim is mandatory if unwinding is not allowed for soundness

I'm talking about the case where unwinding is allowed. I remember you saying that this combination would be inconsistent:

Kyle Strand (Oct 31 2019 at 18:27, on Zulip):

...and I believe that's the combination Niko is describing above.

Kyle Strand (Oct 31 2019 at 18:27, on Zulip):

i.e., if we say that "C" ABI permits unwinding, but the function must be declared to unwind, and by-pointer calls assume it may unwind

in this message

centril (Oct 31 2019 at 18:27, on Zulip):

that seems inconsistent yes

Kyle Strand (Oct 31 2019 at 18:28, on Zulip):

Okay, glad I remembered correctly :smile:

nikomatsakis (Oct 31 2019 at 18:28, on Zulip):

I thought so, but now i'm not so sure.

nikomatsakis (Oct 31 2019 at 18:28, on Zulip):

It also depends a lot on the defaults.

centril (Oct 31 2019 at 18:28, on Zulip):

@nikomatsakis You are talking about the distinction between FnDef and FnPtr?

nikomatsakis (Oct 31 2019 at 18:29, on Zulip):

But it seems like a big part of this question is also a matter of costs -- like, if the worst part of "C unwinds" is the need for an abort shim on call sites, how much does that really cost in actual programs? can we readily measure that?

nikomatsakis (Oct 31 2019 at 18:29, on Zulip):

it seems eminently measurable

centril (Oct 31 2019 at 18:30, on Zulip):

@nikomatsakis at any rate, we have pre-triage now :slight_smile:

nikomatsakis (Oct 31 2019 at 18:30, on Zulip):

yes, I know.

gnzlbg (Oct 31 2019 at 18:33, on Zulip):

one open question with the unwind by default, nounwind opt-in, is how to apply #[unwind(aborts)] to function pointers

gnzlbg (Oct 31 2019 at 18:33, on Zulip):

but that's more a syntactic issue

Amanieu (Oct 31 2019 at 19:07, on Zulip):

For #[unwind(aborts)], it is the responsibility of the callee to ensure that it aborts instead of unwinding. From the caller's point of view it's just a nounwind function. So there isn't much to do with function pointers: by default they can unwind and specifying nounwind function pointers probably isn't worth the trouble.

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

maybe, that was an unresolved question last time

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

in case we wanted to do that in the future #[unwind(aborts)] can just be allowed when specifying function pointers, that would be a backward compatible change

acfoltzer (Nov 07 2019 at 18:27, on Zulip):

hey folks, I'm going to be a bit late to the sync this week as we have a contractor at the house still

nikomatsakis (Nov 07 2019 at 18:33, on Zulip):

:wave:

nikomatsakis (Nov 07 2019 at 18:33, on Zulip):

Hey @WG-ffi-unwind -- quick sync? I'm not sure if anything happened this week, though

nikomatsakis (Nov 07 2019 at 18:34, on Zulip):

I would be happy to spend a bit of time now on looking over the hackmd

acfoltzer (Nov 07 2019 at 18:49, on Zulip):

okay, contractors just finished up. I could take a look at a hackmd—which one?

nikomatsakis (Nov 07 2019 at 18:51, on Zulip):

https://hackmd.io/ymsEL6OpR6OSMoFr1As1rw

nikomatsakis (Nov 07 2019 at 18:52, on Zulip):

I've not done anything, I got distracted by a million other pings :)

nikomatsakis (Nov 07 2019 at 18:52, on Zulip):

But I was saying last week that I felt like the organization wasn't right anymore

nikomatsakis (Nov 07 2019 at 18:52, on Zulip):

Let me take 10 minutes to see...

acfoltzer (Nov 07 2019 at 18:52, on Zulip):

gotcha, taking a look now. I likewise have been on other things for the last week, but we're getting close to the end of this demo sprint

acfoltzer (Nov 07 2019 at 18:53, on Zulip):

also the Cranelift PR for eh_frame data is active once again, so this is really going to be occupying my attention again soon

nikomatsakis (Nov 07 2019 at 18:54, on Zulip):

what I didn't like about this framing

nikomatsakis (Nov 07 2019 at 18:54, on Zulip):

for one thing I didnj't like the lsit of two options

nikomatsakis (Nov 07 2019 at 18:55, on Zulip):

I thnk i'd like to sort of collapse the list of arguments into broader "considerations"

nikomatsakis (Nov 07 2019 at 18:55, on Zulip):

I'm creating a second hackmd to play around

nikomatsakis (Nov 07 2019 at 18:58, on Zulip):

@Taylor Cramer -- you mentioned that Fuschia had some numbers regarding the cost of -Cpanic=abort vs -Cpanic=unwind somewhere?

nikomatsakis (Nov 07 2019 at 18:58, on Zulip):

I know that @gnzlbg had some smaller measurements

gnzlbg (Nov 07 2019 at 19:02, on Zulip):

I only had some synthetic examples, where the impact was massive, but it is hard to extrapolate from there to a real application. An App where ~0% of the code does C FFI calls won't probably see any differences, but an FFI wrapper might or might not see some, depending on other factors like whether it uses variables with destructors in the frames doing FFI calls, etc.

gnzlbg (Nov 07 2019 at 19:03, on Zulip):

Maybe it would be interesting to benchmark, e.g., mozjpeg or similar with -C panic=abort and -C panic=unwind.

nikomatsakis (Nov 07 2019 at 19:03, on Zulip):

I agree

Taylor Cramer (Nov 07 2019 at 19:04, on Zulip):

cc @tmandry who is the better person to talk with about fuchsia stuff going forwards

gnzlbg (Nov 07 2019 at 19:04, on Zulip):

It's a wrapper over mozjpeg-sys, so the impact there can be big, but if it turns out it is small, it is probably safe to conclude that this won't impact large apps except for maybe pathological cases

Taylor Cramer (Nov 07 2019 at 19:04, on Zulip):

and is the one who collected the most recent data on this

Taylor Cramer (Nov 07 2019 at 19:05, on Zulip):

We (fuchsia) also have a decently large amount of FFI, and so would probably be an interesting benchmark for this specific case as well

nikomatsakis (Nov 07 2019 at 19:06, on Zulip):

yes, it seems like a perfect case to measure

nikomatsakis (Nov 07 2019 at 19:06, on Zulip):

of course the cost of -Cpanic=unwind is greater than the cost would be to just have abort guards on FFI calls

nikomatsakis (Nov 07 2019 at 19:06, on Zulip):

but it's a good and easy to measure upper bound

nikomatsakis (Nov 07 2019 at 19:06, on Zulip):

(I think it's an upper bound?)

acfoltzer (Nov 07 2019 at 19:09, on Zulip):

the addendum in the first hackmd about nounwind fn foo() is really interesting; it hadn't occurred to me but of course makes a lot of sense that people would use a nounwind C ABI to implement targeted no-panic guarantees

Kyle Strand (Nov 07 2019 at 19:17, on Zulip):

Hey all, sorry I missed this sync session, and generally haven't been very helpful this week. @nikomatsakis let me know if you think it would be valuable for me to attend the lang meeting; I believe we don't have a real update since last meeting, though.

nikomatsakis (Nov 07 2019 at 19:19, on Zulip):

I think it's ok to say "no update, we're still working on preparing this core question"

nikomatsakis (Nov 07 2019 at 19:20, on Zulip):

I mean I also think this is a pretty important question to get right!

nikomatsakis (Nov 07 2019 at 19:20, on Zulip):

"the rest is details"

nikomatsakis (Nov 07 2019 at 19:20, on Zulip):

I think we've kind of covered the space

nikomatsakis (Nov 07 2019 at 19:20, on Zulip):

in terms of considerations

nikomatsakis (Nov 07 2019 at 19:29, on Zulip):

ok so I've been working on this alternate form

nikomatsakis (Nov 07 2019 at 19:30, on Zulip):

what I am trying to do is to factor out some of the "considerations" that are common, without getting into too much detail about specific approaches

nikomatsakis (Nov 07 2019 at 19:30, on Zulip):

what I wanted to do next is to create a section where I talk about the various options and try to explain their pros/cons in terms of those considerations

nikomatsakis (Nov 07 2019 at 19:30, on Zulip):

I'm running out of time to work on that :)

Kyle Strand (Nov 07 2019 at 19:46, on Zulip):

meaning of C == meaning of the "C" ABI specifier ?

Kyle Strand (Nov 07 2019 at 19:47, on Zulip):

I will try to spend some time looking at that in the next few days

nikomatsakis (Nov 14 2019 at 18:28, on Zulip):

I might be late and/or miss a meeting today, @WG-ffi-unwind

Kyle Strand (Nov 14 2019 at 18:44, on Zulip):

Shoot, I forgot this was right after the release team meeting.

Kyle Strand (Nov 14 2019 at 18:45, on Zulip):

Want to sync up now?

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

OK, I'm around now -- not sure that there is much to say

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

At this point I still really want to see some data

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

It looks like I've gotten "close" to implementing the changes needed, I have to incorporate what @Amanieu mentioned

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

And then probably bug @tmandry to find out how to replicate their numbers but with a local build?

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

Not sure how hard that will be

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

Or I guess it doesn't have to be me who does that

nikomatsakis (Nov 14 2019 at 18:48, on Zulip):

In fact it seems like it would be better if it were someone else :)

nikomatsakis (Nov 14 2019 at 18:48, on Zulip):

Ah one thing I did want to talk to you about @Kyle Strand was that I think we are ripe for an internals blog post

nikomatsakis (Nov 14 2019 at 18:48, on Zulip):

er, "Inside Rust"

nikomatsakis (Nov 14 2019 at 18:48, on Zulip):

Maybe introducing the group with a bit of background, talking about how the first big discussion has to do with "C", and encouraging people to check out the hackmd, come to the zulip channel, something like that?

Kyle Strand (Nov 14 2019 at 18:51, on Zulip):

"All areas of life progressively come to resemble TODO lists" - me, inside my head, often

Kyle Strand (Nov 14 2019 at 18:52, on Zulip):

That sounds good. I'm sorry I haven't been active here this week. I need to take some days off work and catch up on the rest of my life.

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

:/

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

Oh please never apologize for that :)

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

To be clear, I think we're making good progress

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

I feel like at this point we've really bottomed out the pros/cons around the extern "C" thing fairly deeply

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

We're missing some data and we need to kind of have a chat and try to "make a call"

Kyle Strand (Nov 14 2019 at 18:53, on Zulip):

My third sentence was intended to be merely informational, not a continuation of the apology :laughing:

nikomatsakis (Nov 14 2019 at 18:54, on Zulip):

Are you interested in trying to write said blog post?

Kyle Strand (Nov 14 2019 at 18:55, on Zulip):

Maybe - I think that a higher-priority use of my time, when I have some, would be to get our "summaries & current status" documents in a good state.

Kyle Strand (Nov 14 2019 at 18:55, on Zulip):

Especially if we hope to get new contributors to the discussion via this blog post

Kyle Strand (Nov 14 2019 at 18:56, on Zulip):

I agree about needing to have a chat to "make the call." I want to talk to Centril more about the "FFI is not a sandbox" point - he left a response in the HackMD saying the verbiage there was "not justified", but I'm still pretty convinced that it's a valid concern.

nikomatsakis (Nov 14 2019 at 18:56, on Zulip):

one thing -- we do now have the two documents

nikomatsakis (Nov 14 2019 at 18:56, on Zulip):

I would prefer to deprecate the first one :)

Kyle Strand (Nov 14 2019 at 18:57, on Zulip):

the two HackMDs?

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

at least two, but yeah

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

the one centril commented on is the older one

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

I'm curious if other people feel the second one is better :)

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

I don't have the "FFI is not a sandbox" thing in there

Kyle Strand (Nov 14 2019 at 18:57, on Zulip):

two documents about extern "C" considerations? Yes, at most one should be introduced to the master branch of the Repo.

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

at least not "explicitly", but I do have the

nikomatsakis (Nov 14 2019 at 18:58, on Zulip):

well I do have a section about exposing the "full" ABI

nikomatsakis (Nov 14 2019 at 18:58, on Zulip):

I think that quote could be added, potentially, though I'm not sure how imp't it is

nikomatsakis (Nov 14 2019 at 18:58, on Zulip):

Newer document: "meaning of the C abi"

Kyle Strand (Nov 14 2019 at 18:58, on Zulip):

I think the "sandbox" quote captures something important, but doesn't do so in a clear/unambiguous way (which makes sense because it's just a snippet from a personal email).

nikomatsakis (Nov 14 2019 at 18:59, on Zulip):

I think what could be improved in this doc a bit

nikomatsakis (Nov 14 2019 at 18:59, on Zulip):

hmm have to think about it

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

well what I find compelling in this structure is reading the options at the end

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

maybe I should move them to the front :)

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

and trying to tell different "stories"--

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

anyway

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

I haven't made up my mind yet, in any case

nikomatsakis (Nov 14 2019 at 19:01, on Zulip):

Though I am much more sympathetic to the "noexcept is an orthogonal consideration from ABI" POV that I thought I was

nikomatsakis (Nov 14 2019 at 19:01, on Zulip):

but I think it has to come paired with the more permissive defaults

nikomatsakis (Nov 14 2019 at 19:01, on Zulip):

i.e., if extern "C" fns make it UB to unwind by default

nikomatsakis (Nov 14 2019 at 19:01, on Zulip):

I think that combination is strictly worse than "C unwind" ABI

Kyle Strand (Nov 14 2019 at 19:04, on Zulip):

Though I am much more sympathetic to the "noexcept is an orthogonal consideration from ABI" POV that I thought I was

I think that at least partially captures the "FFI is not a sandbox" concern.

Kyle Strand (Nov 14 2019 at 19:04, on Zulip):

They're at least tightly coupled.

Kyle Strand (Nov 14 2019 at 19:04, on Zulip):

I absolutely agree that UB-by-default is strictly worse than not-UB-by-default.

Kyle Strand (Nov 14 2019 at 19:05, on Zulip):

And I think in that sense, making ABI boundaries have some "sandbox" qualities _is_ in line with Rust's goals and language-values.

Kyle Strand (Nov 14 2019 at 19:08, on Zulip):

Or, to remove the word "sandbox" entirely:

Kyle Strand (Nov 14 2019 at 19:09, on Zulip):

In any case, I think this is a reasonable TODO list for me, with a soft deadline of...let's say this time next week:

nikomatsakis (Nov 14 2019 at 19:11, on Zulip):

I think that at least partially captures the "FFI is not a sandbox" concern.

I agree

Kyle Strand (Nov 14 2019 at 19:11, on Zulip):

That's roughly in order of what I think my priorites ought to be.

nikomatsakis (Nov 14 2019 at 19:11, on Zulip):

I don't think I would waste a lot of time scraping zulip

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

but I do think that updating the repo is maybe good

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

in particular, our roadmap seems wrong

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

i.e., we have a "step 0" I thought was settled

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

but it seems is not

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

and we've not updated that

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

("figuring out the overall direction")

Kyle Strand (Nov 14 2019 at 19:18, on Zulip):

What I want to try to do vis-a-vis Zulip is maintain a document that we can point to such that anyone who reads it (whether they're newcomers or haven't visited the stream in a while) should feel equipped to participate in the conversation without needing to read too far back in Zulip history.

Kyle Strand (Nov 14 2019 at 19:18, on Zulip):

I think my original approach of "summarize each week's Zulip activity" may not be the most efficient way to do that, but I'd still like to find some way to accomplish the goal.

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

Yes.

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

I do think that's a super good goal

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

I guess what I'm contending .. hmm, what am I contending

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

One observation is that while I like the hackmd approach, I do often wish for a "go deeper" option

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

A wiki is a plausible structure here

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

(We could even use GH's wikis)

nikomatsakis (Nov 14 2019 at 19:22, on Zulip):

i.e., I'd like to start from "here are the proposals and some pros and cons"

nikomatsakis (Nov 14 2019 at 19:22, on Zulip):

and be able to click from a given pro to learn more about the thing in question

nikomatsakis (Nov 14 2019 at 19:22, on Zulip):

but I also feel a "woah diminishing returns" flag going on

Kyle Strand (Nov 14 2019 at 19:22, on Zulip):

Yes

Kyle Strand (Nov 14 2019 at 19:22, on Zulip):

Hmmm

nikomatsakis (Nov 14 2019 at 19:22, on Zulip):

lots of work to organize this information and not obviously worth the effort :)

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

though if we found a good structure, it might be less work overall

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

and I am deeply concerned about the way our current practices

Kyle Strand (Nov 14 2019 at 19:23, on Zulip):

Well, to be fair, the topics in the stream are decently well named, so anyone interested in the history of a given question can probably find what they want.

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

leave us with a very confusing "design trail"

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

I want to be able to come back to this decision in a year, two years, etc, and clearly lay out what we took into account

Kyle Strand (Nov 14 2019 at 19:23, on Zulip):

Yes!

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

Well, to be fair, the topics in the stream are decently well named, so anyone interested in the history of a given question can probably find what they want.

well I sort of imagine that

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

the wiki page would link to zulip topics

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

i.e., that's the "deepest"

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

so the wiki page might just be roughly what's in the current hackmd, but also have links to zulip topics where you can read more

Kyle Strand (Nov 14 2019 at 19:24, on Zulip):

Agreed. That's what I did in my first "summary" doc, but unfortunately that was probably the most time-consuming aspect

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

or rather, the "sections" of the current hackmd might each be a wiki page

Kyle Strand (Nov 14 2019 at 19:24, on Zulip):

Hm....it would be nice to be able to "tag" old Zulip messages.

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

well, you could just link to the topics in general

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

and not try to link to specific messages within

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

like "this was discussed here"

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

I'm imagining like

nikomatsakis (Nov 14 2019 at 19:25, on Zulip):

Interaction with -Cpanic=abort and UB

Today, the -Cpanic=abort feature works by changing panic!() to cause an immediate abort at the site of panic. This in turn means we can remove all the "landing pads" and thus remove the impact of unwinding completely.

However, if the source of the unwinding is foreign code that is not possible. Instead, if we wish to avoid UB, we have to add landing pads to the call sites of any foreign function that may unwind, such that we can abort when the unwinding enters into a Rust frame. Note that all designs include ways to indicate foreign functions that cannot unwind, though they vary in defaults and approach. Inserting these landing pads has a certain cost, though it is less than the full cost of -Cpanic=unwind (since in that case landing pads are required on all call sites, not just foreign call sites).

You might ask "why not just have it be UB to invoke a foreign function that unwinds with -Cpanic=abort?" The problem here is that then you can have libraries which compile under both modes but which produce UB when executed with -Cpanic=abort. If we install "abort guards", those same libraries would merely abort at runtime, which is much more noticeable.

If you come from C++, this might not seem like a big deal. After all, mixing -fexceptions code with code with -fno-exceptions code is going to mess everything up. But it's the kind of low-level footgun we'd prefer to avoid in Rust if we can.

Discussed on:

nikomatsakis (Nov 14 2019 at 19:25, on Zulip):

maybe that's a ton of work to keep up to date too :)

nikomatsakis (Nov 14 2019 at 19:26, on Zulip):

I want to be able to come back to this decision in a year, two years, etc, and clearly lay out what we took into account

also, to be clear, I think we're doing way better than ever before here

Kyle Strand (Nov 14 2019 at 19:28, on Zulip):

Agreed - when discussing my original RFCs, I found several old relevant GitHub threads quite late in the process

Kyle Strand (Nov 14 2019 at 19:44, on Zulip):

I think as a first pass, making that map from design questions to Zulip-topics is more important than writing new "summary" verbiage for each question.

Kyle Strand (Nov 14 2019 at 19:44, on Zulip):

The summarizing effort can then be done by anyone at any time

Kyle Strand (Nov 14 2019 at 19:44, on Zulip):

If indeed it's even necessary.

Kyle Strand (Nov 14 2019 at 19:48, on Zulip):

Anyway, for now I'll plan on following my "TODO" list above, with the caveat that I'll try to keep my time investment into "Zulip summary/links" docs minimal.

centril (Nov 14 2019 at 22:36, on Zulip):

@Kyle Strand "not justified" in the sense that a claim is being made like "this is the way it is" without the "why"

Kyle Strand (Nov 18 2019 at 00:08, on Zulip):

@nikomatsakis Here's my effort to remove the assumption that we'll move forward with "C unwind": https://github.com/rust-lang/project-ffi-unwind/pull/18

Kyle Strand (Nov 18 2019 at 01:43, on Zulip):

And here is my links-to-Zulip PR: https://github.com/rust-lang/project-ffi-unwind/pull/19

Kyle Strand (Nov 18 2019 at 01:49, on Zulip):

And one more: https://github.com/rust-lang/project-ffi-unwind/pull/20

Kyle Strand (Nov 18 2019 at 01:52, on Zulip):

I'm going to leave off w/ PRs for the time being. I am wondering if the project-planning document (with some modifications) could work as the primary "current status" document; what do you think?

nikomatsakis (Nov 18 2019 at 11:02, on Zulip):

the difference is basically whether to have the table or whether to have the list of checkboxes with specific ongoing tasks?

nikomatsakis (Nov 18 2019 at 11:02, on Zulip):

I think either could be fine

nikomatsakis (Nov 18 2019 at 11:03, on Zulip):

I merged rust-lang/project-ffi-unwind#18 but I think the others have conflicts, @Kyle Strand

Kyle Strand (Nov 19 2019 at 17:28, on Zulip):

the difference is basically whether to have the table or whether to have the list of checkboxes with specific ongoing tasks?

As I understood it, they're not really overlapping; the table is for project-scope, while the list is for immediate action items

Kyle Strand (Nov 19 2019 at 17:31, on Zulip):

@nikomatsakis thanks; the conflicts are resolved

acfoltzer (Nov 21 2019 at 17:48, on Zulip):

Hey folks, just a heads up that I have an appointment scheduled against our regular meeting time. Just to kick things off asynchronously:

nikomatsakis (Nov 21 2019 at 18:33, on Zulip):

@acfoltzer can you elaborate on the connection between malloc/free and unwinding?

Kyle Strand (Nov 21 2019 at 18:34, on Zulip):

@nikomatsakis I think you know my status already, but just to be explicit: I did do the "Zulip summary" task (my PRs), and I did have my conversation with Centril; I did not yet add anything to the "meaning of extern 'C'" doc, nor did I draft a blog post

nikomatsakis (Nov 21 2019 at 18:34, on Zulip):

Actually I don't know the status :)

nikomatsakis (Nov 21 2019 at 18:34, on Zulip):

I'm quite behind

nikomatsakis (Nov 21 2019 at 18:34, on Zulip):

BTW, I'll be away next week for vacation

nikomatsakis (Nov 21 2019 at 18:35, on Zulip):

But that all sounds pretty good, I guess we should merge some PRs?

nikomatsakis (Nov 21 2019 at 18:35, on Zulip):

In my view the single biggest remaining item is still to improve that branch I started and get some measurements?

nikomatsakis (Nov 21 2019 at 18:35, on Zulip):

I guess one question might be if there were any take-aways from conversation with @centril you can crystallize :)

nikomatsakis (Nov 21 2019 at 18:35, on Zulip):

or maybe it's in the PRs

centril (Nov 21 2019 at 18:36, on Zulip):

:wave: -- I think our conversation needs more participation from me

centril (Nov 21 2019 at 18:36, on Zulip):

(but I'm trying to cut down on my unread emails atm... :sweat_smile: )

Kyle Strand (Nov 21 2019 at 18:36, on Zulip):

In my view the single biggest remaining item is still to improve that branch I started and get some measurements?

The rustc branch?

Kyle Strand (Nov 21 2019 at 18:37, on Zulip):

I did not summarize the discussion w/ Centril in the PRs I've already submitted. I think the conversation was reasonably short & to the point, but I do still plan to write up a short summary

Kyle Strand (Nov 21 2019 at 18:37, on Zulip):

Maybe I can even do that today

nikomatsakis (Nov 21 2019 at 18:38, on Zulip):

The rustc branch?

confirm

nikomatsakis (Nov 21 2019 at 18:38, on Zulip):

One thing I could do is try to write out what steps are needed in my view

Kyle Strand (Nov 21 2019 at 18:38, on Zulip):

(but I'm trying to cut down on my unread emails atm... :sweat_smile: )

I sympathize greatly!

nikomatsakis (Nov 21 2019 at 18:39, on Zulip):

(I'm actually not entirely sure)

Kyle Strand (Nov 21 2019 at 18:40, on Zulip):

Do you intend your branch to be a possible prototype for an actual recommended rustc change (i.e. as part of a future PR)? Or is it just for measuring?

nikomatsakis (Nov 21 2019 at 18:42, on Zulip):

sorry, scarfing down a hasty lunch

nikomatsakis (Nov 21 2019 at 18:42, on Zulip):

uh, I think it would be both, but I'm more interested in the measurement

nikomatsakis (Nov 21 2019 at 18:43, on Zulip):

anyway th eonly work that's left, I think, is to tweak which fns get which attributes

nikomatsakis (Nov 21 2019 at 18:45, on Zulip):

I would like to see an actual execution where a throw from C++ gets intercepted :)

nikomatsakis (Nov 21 2019 at 18:45, on Zulip):

though I guess that this means adding some attributes which can be used to figure out how to unwind

nikomatsakis (Nov 21 2019 at 18:45, on Zulip):

and given that the only purpose to unwinding is so we can abort..

nikomatsakis (Nov 21 2019 at 18:46, on Zulip):

I'm not sure if those attributes actually make that much sense? I guess it depends on the platform, too

Kyle Strand (Nov 21 2019 at 18:46, on Zulip):

"how" to unwind?

Kyle Strand (Nov 21 2019 at 18:48, on Zulip):

Maybe I need to just take a look at the branch

nikomatsakis (Nov 21 2019 at 18:48, on Zulip):

yes, specifically the uwtable attribute

nikomatsakis (Nov 21 2019 at 18:48, on Zulip):

anyway maybe I'll open an issue and leave some notes

nikomatsakis (Nov 21 2019 at 18:48, on Zulip):

I could imagine trying to recruit someone to push on this

nikomatsakis (Nov 21 2019 at 18:49, on Zulip):

presuming none of us have the time

nikomatsakis (Nov 21 2019 at 18:49, on Zulip):

I guess I can open an issue on ... rust-lang/rust? maybe project-ffi-unwind? :)

Kyle Strand (Nov 21 2019 at 18:50, on Zulip):

project-ffi-unwind seems appropriate, though low-visibility...

Kyle Strand (Nov 21 2019 at 18:50, on Zulip):

though that may be alleviated by posting a blog post when I get around to drafting it

Kyle Strand (Nov 21 2019 at 18:54, on Zulip):

Niko, would you like to revise the open RFC to incorporate the changes to the "scope" verbiage, or should I?

acfoltzer (Nov 21 2019 at 21:43, on Zulip):

acfoltzer can you elaborate on the connection between malloc/free and unwinding?

sorry, I had to run shortly after writing this message; malloc and free are the primary use cases for callbacks into a Wasm guest from Rust code, which leave open the possibility that the guest callback could fault and leave Rust frames on the stack.

acfoltzer (Nov 21 2019 at 21:44, on Zulip):

specifically, suppose you want to copy a string into the Wasm linear memory from outside Wasm; you need to know where to put those bytes in memory. either the guest provides a pointer to a buffer and a maximum size, or you can call back into the guest's malloc, and use the pointer it gives back to you

acfoltzer (Nov 21 2019 at 21:46, on Zulip):

currently it's looking like we'll be doing the former approach for the first draft of the API, but the interface-types proposal uses malloc/free as part of the adapter expressions that are used to know how to move complex types between modules

acfoltzer (Nov 21 2019 at 21:47, on Zulip):

oh whoops, the quote feature doesn't ping; cc @nikomatsakis

acfoltzer (Dec 05 2019 at 18:32, on Zulip):

hey folks, no updates from me again this week; still heads down in building out our product. the outlook on our need for FFI unwinding remains the same as my last update: we won't need it in the short term due to some self-imposed restrictions on our use of Wasm, but will need it in the longer term to keep up with additional Wasm specs like interface-types

nikomatsakis (Dec 05 2019 at 18:34, on Zulip):

Hi all =) I didn't really do anything since last week either

Kyle Strand (Dec 05 2019 at 18:34, on Zulip):

I have been sick, plus the holidays, so no update here either :/

gnzlbg (Dec 05 2019 at 18:44, on Zulip):

I'm back from travelling

nikomatsakis (Dec 05 2019 at 18:55, on Zulip):

Sorry, got pulled into something -- I'd still like to get some "figures" on what impact these results have on code size.

nikomatsakis (Dec 05 2019 at 18:55, on Zulip):

I did not find time to write up any kind of instructions on what still needs to be done in that regard

nikomatsakis (Dec 05 2019 at 19:21, on Zulip):

(To that end, I've spent the last little bit trying to get a new desktop setup to build Rust :)

nikomatsakis (Dec 12 2019 at 18:41, on Zulip):

Hey @WG-ffi-unwind

nikomatsakis (Dec 12 2019 at 18:41, on Zulip):

So I've still not had time to do anything

nikomatsakis (Dec 12 2019 at 18:42, on Zulip):

But I did have an interesting chat with @Josh Triplett

nikomatsakis (Dec 12 2019 at 18:42, on Zulip):

I feel like we need to organize a meeting to have an in-depth chat with lang team; maybe we should schedule it for very early January or something

nikomatsakis (Dec 12 2019 at 18:42, on Zulip):

and give ourselves a deadline to get data or just make the decision without data

nikomatsakis (Dec 12 2019 at 18:43, on Zulip):

The main thing I got from my chat with @Josh Triplett was that one use case we should be sure we are able to accommodate is the case where it is UB to unwind and hence we have zero extract overhead. I think that if we declared that "C" can unwind, the way we would accommodate that is by having every extern "C" fn declared with #[unwind(never)] or some such annotation.

nikomatsakis (Dec 12 2019 at 18:43, on Zulip):

This might suffice, @Josh Triplett was thinking primarily of cases where people are literally counting bytes, which I imagine can afford a bit of extra annotation, but it's still worth thinking about.

nikomatsakis (Dec 12 2019 at 18:44, on Zulip):

Or maybe there wants to be a -Cpanic=ub flag =)

nikomatsakis (Dec 12 2019 at 18:44, on Zulip):

Or of course the C+unwind design

Kyle Strand (Dec 12 2019 at 18:45, on Zulip):

Sorry, no update from me again. I do want to circle back on RFC #2797, the one announcing the project group, and see if we can get it merged soon.

acfoltzer (Dec 12 2019 at 18:45, on Zulip):

sorry to be late, I'm at the Bytecode Alliance meeting (with Josh, incidentally)

Kyle Strand (Dec 12 2019 at 18:49, on Zulip):

By "he case where it is UB to unwind", do you mean where the user _wants_ it to be UB, or where it's undefined for some other reason?

nikomatsakis (Dec 12 2019 at 18:50, on Zulip):

Sorry, no update from me again. I do want to circle back on RFC #2797, the one announcing the project group, and see if we can get it merged soon.

oh geez :)

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

By "the case where it is UB to unwind", do you mean where the user _wants_ it to be UB, or where it's undefined for some other reason?

I mean where the user wants it to be UB, because they want the compiler to optimize everything away

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

in particular, they do not want the "shim" that aborts, no matter how small it is

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

My belief (yet to be verified with data) is that such a shim will be negligible for the vast majority of use cases

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

@Josh Triplett's point is that there will always be cases for which no increase is acceptable, and we should be able to accommodate that

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

I think that sounds correct, but I also suspect that some add'l effort is ok in such cases

Kyle Strand (Dec 12 2019 at 18:53, on Zulip):

I think giving users the _ability_ to avoid such shims makes the cost less important. In general, this is a cost that the "systems programming" world has already opted into; the idea is that exceptions are "zero cost unless they're actually used".

nikomatsakis (Dec 12 2019 at 19:05, on Zulip):

@Kyle Strand I think the ergonomics and defaults matter a lot there

nikomatsakis (Dec 12 2019 at 19:06, on Zulip):

I think it's a design failure if people start adding #[unwinds(never)] annotations reflexively because of a concern about cost

nikomatsakis (Dec 12 2019 at 19:07, on Zulip):

but if people do it because they're literally counting bytes, seems ok

nikomatsakis (Dec 12 2019 at 19:09, on Zulip):

I'm not sure where e.g. fuchsia would fall on such a spectrum

nikomatsakis (Dec 12 2019 at 19:09, on Zulip):

anyway I think we should set ourselves some kind of deadline :)

Kyle Strand (Dec 12 2019 at 19:14, on Zulip):

I think we're in agreement, but I also think the broader "systems programming ecosystem" seems to consider landing pads "zero cost" already anyway. (E.g. C++ people will say "exceptions are zero-cost until you actually throw them.") So I think the risk of people adding unwinds(never) by default is low.

Kyle Strand (Dec 12 2019 at 19:15, on Zulip):

As for a deadline... I'm slightly concerned that without #2797 being merged, i.e., without a formal announcement of the project group, people will feel that they didn't have an opportunity to participate, which I get the sense is something you're trying to improve across the Rust project.

Kyle Strand (Dec 12 2019 at 19:17, on Zulip):

So I am tempted to say we can't set a deadline until, say, a week after formally announcing the group; that way, if new voices chime in, we can take that into account.

nikomatsakis (Dec 12 2019 at 19:17, on Zulip):

Interesting. Well, that's just busy work. I can try to do it soon

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

I hadn't considered that people might not realize discussion was active

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

In any case I think we will want to write up a good blog post

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

That summaries the arguments

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

It'd be a good idea to do that before the meeting is scheduled

Kyle Strand (Dec 12 2019 at 19:18, on Zulip):

Yes

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

so that people can start to react and we can take some of that into account during lang team discussion

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

(I guess I can try to update some of the language based on the comment threads, too)

Kyle Strand (Dec 12 2019 at 19:20, on Zulip):

Hm, let's try to have blog ready to post and RFC merged by this time next week, then the first week of January schedule a meeting w/ Lang team

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

mm I'm not sure if that's realistic :)

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

it might be

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

I also still think data would be really, really great

Kyle Strand (Dec 12 2019 at 19:20, on Zulip):

I think the RFC is close and I can work on the blog post

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

This conversion will be much more informed if we can say 1% overhead or something like that

Kyle Strand (Dec 12 2019 at 19:20, on Zulip):

Do you think that needs to be in the blog post?

nikomatsakis (Dec 12 2019 at 19:21, on Zulip):

I think it would be better, yes

Kyle Strand (Dec 12 2019 at 19:21, on Zulip):

(By "the RFC" I just mean the announcement one that's already open)

nikomatsakis (Dec 12 2019 at 19:21, on Zulip):

Yes, I understood

nikomatsakis (Dec 12 2019 at 19:21, on Zulip):

it probably just takes a few hours of focus to get data

nikomatsakis (Dec 12 2019 at 19:21, on Zulip):

/me ponders

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

I got stuck the lsat time because my desktop was dead

Kyle Strand (Dec 12 2019 at 19:22, on Zulip):

Okay. Is that few hours mostly for getting your fork of rustc into a state for taking the metrics?

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

but I've got an updated one up and going now :)

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

Okay. Is that few hours mostly for getting your fork of rustc into a state for taking the metrics?

yeah

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

I may be underestimating of course

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

but I think it's close

Kyle Strand (Dec 12 2019 at 19:22, on Zulip):

Hm, maybe this is a good time for me to dive in and try to help with that.

Kyle Strand (Dec 12 2019 at 19:25, on Zulip):

Well, I think we can get the announcement RFC merged, anyway, and I can start drafting a blog post with <TODO> placeholder for when some data is available.

Kyle Strand (Dec 12 2019 at 19:29, on Zulip):

Can you expand a bit on why the initial blog post should have data? Your original description sounded more like an announcement and invitation-to-participate; if that's the goal, I think making a note that we could use some help w/ the data-collection effort would actually be better than a final result from that effort.

nikomatsakis (Dec 12 2019 at 19:32, on Zulip):

I guess it depends

nikomatsakis (Dec 12 2019 at 19:32, on Zulip):

I don't think data is required

nikomatsakis (Dec 12 2019 at 19:32, on Zulip):

Maybe not worth blocking on

nikomatsakis (Dec 12 2019 at 19:33, on Zulip):

I'm basically concerned about knee-jerk reactions

Kyle Strand (Dec 12 2019 at 19:33, on Zulip):

True....

Kyle Strand (Dec 12 2019 at 19:34, on Zulip):

Well, I'll try to be more available this week, and I'll start w/ getting the RFC comments addressed

nikomatsakis (Dec 12 2019 at 19:34, on Zulip):

but I think if we leave a placeholder like "we really want to measure this" it is also fine

Kyle Strand (Dec 13 2019 at 02:06, on Zulip):

(deleted)

Kyle Strand (Dec 17 2019 at 21:46, on Zulip):

I had some family health issues come up and will not have as much time as I thought I would this week.

Kyle Strand (Dec 19 2019 at 18:35, on Zulip):

Hey @nikomatsakis, @acfoltzer - nothing to report. I should have time to draft a blog post next week, since I'll be on leave for the holidays. Shall we plan to reconvene next year, on the 2nd?

nikomatsakis (Dec 19 2019 at 18:41, on Zulip):

Hey @Kyle Strand -- running slow today myself

nikomatsakis (Dec 19 2019 at 18:41, on Zulip):

I think reconvening makes sense. My main next step -- which I'll do right now -- was going to be e-mailing to the lang team to make another effort to organize a time for in-depth disussion (both of this but also other topics)

nikomatsakis (Dec 19 2019 at 18:42, on Zulip):

I feel like I've about given up on an attempt to gather data. I suppose I could try to measure the size of Fuchsia with my existing branch, as it's probably "pretty close" to what the cost would be.. maybe an upper bound, even.

nikomatsakis (Dec 19 2019 at 18:43, on Zulip):

To that end, @tmandry, how hard would it be for me to measure the size of a Fuchsia binary?

nikomatsakis (Dec 19 2019 at 18:49, on Zulip):

(Whatever it was that you measured to get that 10% "binary size" figure)

tmandry (Dec 19 2019 at 19:26, on Zulip):

@nikomatsakis I can measure one thing if you want, or I can point you to instructions to building a rust toolchain for fuchsia + building fuchsia with it

nikomatsakis (Dec 19 2019 at 19:26, on Zulip):

@tmandry is it a pain to build with a custom rust toolchain? I basically wanted to do a build with this branch I made.

tmandry (Dec 19 2019 at 19:27, on Zulip):

well, it's just something that I think I still need to document ;)

tmandry (Dec 19 2019 at 19:27, on Zulip):

it's not a huge pain, though

tmandry (Dec 19 2019 at 19:28, on Zulip):

I'll throw some notes in a doc

tmandry (Dec 20 2019 at 00:15, on Zulip):

@nikomatsakis sent you an email, feel free to share any of it

tmandry (Dec 20 2019 at 00:15, on Zulip):

(sorry, I should document it in a more public place, but leaving tomorrow)

Kyle Strand (Jan 02 2020 at 18:31, on Zulip):

@nikomatsakis @acfoltzer Nothing much to report. I have started drafting a blog post, for which I've posted a link in #project-ffi-unwind > Blog post .

nikomatsakis (Jan 02 2020 at 18:39, on Zulip):

Hi :)

nikomatsakis (Jan 02 2020 at 18:40, on Zulip):

I was going to spend some time going over blog post and giving feedback

Kyle Strand (Jan 02 2020 at 18:40, on Zulip):

Sounds reasonable.

nikomatsakis (Jan 02 2020 at 18:40, on Zulip):

Do you have outstanding edits, @Kyle Strand ?

nikomatsakis (Jan 02 2020 at 18:41, on Zulip):

I guess the other thing is to schedule a time to chat w/ lang team

nikomatsakis (Jan 02 2020 at 18:41, on Zulip):

We've now created a Monday "in depth meeting slot"

nikomatsakis (Jan 02 2020 at 18:41, on Zulip):

Does Monday at noon EST work for folks? (cc @acfoltzer) -- I should create a doodle to find a good week

Kyle Strand (Jan 02 2020 at 18:42, on Zulip):

I don't have unpushed changes or anything, but the draft isn't complete

nikomatsakis (Jan 02 2020 at 18:42, on Zulip):

in particular I was thining I might make edits

Kyle Strand (Jan 02 2020 at 18:42, on Zulip):

noon EST Monday is okay.

Kyle Strand (Jan 02 2020 at 18:42, on Zulip):

Pushing edits to my branch would be fine.

Kyle Strand (Jan 02 2020 at 18:43, on Zulip):

I've just made you a collaborator on my fork

nikomatsakis (Jan 02 2020 at 18:44, on Zulip):

ok

nikomatsakis (Jan 09 2020 at 18:33, on Zulip):

Hi @WG-ffi-unwind -- so -- I was thinking

nikomatsakis (Jan 09 2020 at 18:34, on Zulip):

I've been wanting to schedule a lang team design meeting to present the details of "C" vs "C unwind" etc

nikomatsakis (Jan 09 2020 at 18:34, on Zulip):

it seems to be surprisingly hard for us to prepare a concise summary though :) (complex ..)

nikomatsakis (Jan 09 2020 at 18:35, on Zulip):

anyway I am wondering if it might hep to schedule like a 1 or 2h block to try to organize the information or plan ahead? not sure what's best.

nikomatsakis (Jan 09 2020 at 18:35, on Zulip):

(also, sync time :)

Kyle Strand (Jan 09 2020 at 18:42, on Zulip):

That sounds reasonable to me.

nikomatsakis (Jan 09 2020 at 18:53, on Zulip):

I guess the trick is to find a time =)

Kyle Strand (Jan 09 2020 at 19:03, on Zulip):

I am pretty flexible and can generally make time when others are available.

nikomatsakis (Jan 09 2020 at 19:28, on Zulip):

some time next week then? I can setup a doodle I guess

nikomatsakis (Jan 09 2020 at 19:28, on Zulip):

or maybe you can @Kyle Strand, if you have a moment

nikomatsakis (Jan 09 2020 at 19:28, on Zulip):

I do thnk it's worth allocating maybe even 2h for this

nikomatsakis (Jan 09 2020 at 19:29, on Zulip):

I also think it should be a relatively small group perhaps -- like you and I could just do it

Kyle Strand (Jan 09 2020 at 19:31, on Zulip):

Okay. Should I exclude weekends?

nikomatsakis (Jan 09 2020 at 20:00, on Zulip):

yes :)

acfoltzer (Jan 09 2020 at 22:05, on Zulip):

hey folks, sorry I've missed the last few check-ins. vacation + big beginning of year planning meetings. I will be available next week for a meeting to feed into the lang team design

nikomatsakis (Jan 09 2020 at 22:25, on Zulip):

oh, that'd be good

nikomatsakis (Jan 09 2020 at 22:26, on Zulip):

the hope @acfoltzer is that we will schedule a sync w/ team on monday Jan 20 at noon Boston time

nikomatsakis (Jan 09 2020 at 22:26, on Zulip):

@Kyle Strand (you're making doodle for next week?)

acfoltzer (Jan 09 2020 at 22:31, on Zulip):

ah, Jan 20 is a holiday for me but I'd be able to make it

Kyle Strand (Jan 10 2020 at 00:05, on Zulip):

Yes, making the doodle now

Kyle Strand (Jan 10 2020 at 00:08, on Zulip):

Are there any other blocks of time we can immediately veto? What's the latest people can go?

Kyle Strand (Jan 10 2020 at 00:09, on Zulip):

Currently I'm just filling in every two-hour block starting on every half-hour from 9:30am MST to 6pm (ending at 8pm) on every day of the week except where I have meetings

Kyle Strand (Jan 10 2020 at 00:13, on Zulip):

And also leaving out the lang team and compiler team meeting times

Kyle Strand (Jan 10 2020 at 00:16, on Zulip):

'kay, here 'tis: https://doodle.com/poll/x4c9xquauteew7gn

Kyle Strand (Jan 10 2020 at 20:30, on Zulip):

@WG-ffi-unwind

acfoltzer (Jan 10 2020 at 21:25, on Zulip):

done; thanks for the ping!

nikomatsakis (Jan 10 2020 at 23:43, on Zulip):

whoosh, that was a very fine-grained poll :) looks like monday afternoon is maybe best...

Kyle Strand (Jan 12 2020 at 19:24, on Zulip):

@Amanieu and @gnzlbg , do you want to participate in the meeting discussed above, and if so, would 6:30 am UTC work for you?

Kyle Strand (Jan 12 2020 at 19:24, on Zulip):

If that time doesn't work, please let us know and fill out the Doodle poll

Amanieu (Jan 12 2020 at 19:28, on Zulip):

I've updated the doodle.

Amanieu (Jan 12 2020 at 19:29, on Zulip):

Monday evening is looking good

gnzlbg (Jan 12 2020 at 19:44, on Zulip):

I've updated the doodle as well

Kyle Strand (Jan 12 2020 at 20:18, on Zulip):

Thanks for the quick response! 6am UTC tomorrow it is.

Kyle Strand (Jan 12 2020 at 20:20, on Zulip):

I've sent an invite to Niko, but I don't seem to have the rest of you in my email contacts list.

Amanieu (Jan 12 2020 at 20:25, on Zulip):

amanieu@gmail.com

Amanieu (Jan 12 2020 at 20:26, on Zulip):

Also, the selected time on doodle is 8pm UTC. Not sure where you got 6am from?

Kyle Strand (Jan 13 2020 at 05:24, on Zulip):

I was adding instead of subtracting to get UTC from my local time. Oops.

gnzlbg (Jan 13 2020 at 17:16, on Zulip):

I have a meeting 1:30h before this one, and it appears to be of unbounded length. I'll try to make it, but I'm not sure if it will work

nikomatsakis (Jan 13 2020 at 18:36, on Zulip):

BTW I don't think the lang-team design meeting will happen until Feb due to MLK Jr Day here in the US

nikomatsakis (Jan 13 2020 at 18:36, on Zulip):

but I still think we should try to get this done

acfoltzer (Jan 16 2020 at 18:29, on Zulip):

Hey folks, I don't really have anything to add since our call. Still pretty underwater working on our product, but unwinding support is making its way into cranelift

Kyle Strand (Jan 16 2020 at 18:34, on Zulip):

I also have nothing to add since our call. I have not had time yet to translate our thoughts Monday into a blog post.

Kyle Strand (Jan 16 2020 at 18:36, on Zulip):

Tangent about cranelift: @nikomatsakis do you have any insight into Cranelift's future? My impression was that (1) Cranelift was primarily supported by Mozilla, and (2) the recent layoffs affected the Cranelift team pretty hard.

nikomatsakis (Jan 16 2020 at 18:36, on Zulip):

I am aware of one layoff from within Cranelift, but there may be more

nikomatsakis (Jan 16 2020 at 18:37, on Zulip):

I don't know more than you do I don't think

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

the main thing I had hoped to touch base on here was who was going to try and translate the stuff from our call into a blog post :)

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

is that you, @Kyle Strand ?

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

I think it's a good idea to produce a document that avoids too much background -- think of the lang team as audience

Kyle Strand (Jan 16 2020 at 18:38, on Zulip):

The spirit is willing but the flesh is time-constrained

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

I think a explainer with background is probably also good but separately :)

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

lol fair

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

I had a few other thoughts after our call

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

one thing I was thinking of

nikomatsakis (Jan 16 2020 at 18:39, on Zulip):

is that I feel like we have a large number of desiderata

nikomatsakis (Jan 16 2020 at 18:39, on Zulip):

that we often failed to remember

nikomatsakis (Jan 16 2020 at 18:39, on Zulip):

e.g., "can insert a shim into extern C fn" or something

nikomatsakis (Jan 16 2020 at 18:39, on Zulip):

maybe a table would make sense

Kyle Strand (Jan 16 2020 at 18:39, on Zulip):

Since the explainer is basically done, maybe I should just post that separately? On its own, it doesn't really seem like useful content for the Internals blog, and unfortunately I don't have a personal blog myself yet, but it seems like it would be useful to put out there in the world somewhere.

Kyle Strand (Jan 16 2020 at 18:40, on Zulip):

Function pointers seem like an oft-neglected consideration

Kyle Strand (Jan 16 2020 at 18:40, on Zulip):

Despite the fact that we're all aware of the complications therein, having previously discussed them!

acfoltzer (Jan 16 2020 at 18:41, on Zulip):

I can help with an editing pass and other feedback but unfortunately my time is extremely constrained

nikomatsakis (Jan 16 2020 at 18:41, on Zulip):

Re: explainer:

nikomatsakis (Jan 16 2020 at 18:41, on Zulip):

I'm not 100% sure what that refers to :)

nikomatsakis (Jan 16 2020 at 18:41, on Zulip):

background material?

nikomatsakis (Jan 16 2020 at 18:41, on Zulip):

if so, maybe push to the repo and then write a blog post announcing it exists

nikomatsakis (Jan 16 2020 at 18:42, on Zulip):

I think people would be interested

Kyle Strand (Jan 16 2020 at 18:43, on Zulip):

I mean the majority of my original draft in that one PR: https://github.com/BatmanAoD/project-ffi-unwind/blob/BlogPost-announcement/blogposts/inside-rust/01-announcement.md

nikomatsakis (Jan 16 2020 at 18:43, on Zulip):

yeah that's what I figured you meant

nikomatsakis (Jan 16 2020 at 18:43, on Zulip):

seems great

Kyle Strand (Jan 16 2020 at 18:44, on Zulip):

I'll move the "should the "C" ABI permit unwinding" section to the bottom and re-cast it as a "preview" of a more in-depth summary of the project group's (PG's?) discussions so far.

nikomatsakis (Jan 16 2020 at 18:45, on Zulip):

+1

nikomatsakis (Jan 16 2020 at 18:45, on Zulip):

I might try my hand at making this table I was talking about

nikomatsakis (Jan 16 2020 at 18:45, on Zulip):

oh and

nikomatsakis (Jan 16 2020 at 18:46, on Zulip):

I plan to schedule a lang team meeting sometime in Feb -- it'll be a design meeting, so monday at noon Eastern time

nikomatsakis (Jan 16 2020 at 18:46, on Zulip):

do y'all have any preferences when it comes to weeks?

Kyle Strand (Jan 16 2020 at 18:46, on Zulip):

Okay. I have no time today but maybe some tomorrow, definitely this weekend, and Monday is a day off for me so... hopefully I'll make some progress on both this and job-search-stuff

nikomatsakis (Jan 16 2020 at 18:46, on Zulip):

I can make a doodle if needed :)

Kyle Strand (Jan 16 2020 at 18:47, on Zulip):

Looks like I have no prior commitments on any Monday in February.

nikomatsakis (Jan 16 2020 at 18:49, on Zulip):

I plan to schedule a lang team meeting sometime in Feb -- it'll be a design meeting, so monday at noon Eastern time

@acfoltzer you seem more likely to have conflicts...

acfoltzer (Jan 16 2020 at 18:49, on Zulip):

the week of the 10th I'm in the bay area for a bunch of wasm meetings

acfoltzer (Jan 16 2020 at 18:50, on Zulip):

as far as other times go, it's less about having specific conflicts on my calendar, and more about overall number of hours I can devote to non-product things

nikomatsakis (Jan 16 2020 at 18:51, on Zulip):

I don't feel you have to attend

acfoltzer (Jan 16 2020 at 18:51, on Zulip):

which is to say, other than the 10th all of my Mondays are pretty much free

nikomatsakis (Jan 16 2020 at 18:51, on Zulip):

I guess @Amanieu your schedule would be pretty relevant too

Amanieu (Jan 16 2020 at 18:51, on Zulip):

I'm away on a ski trip for the 1st week of Feb

acfoltzer (Jan 16 2020 at 18:51, on Zulip):

I would like to, because having a concrete commitment helps me actually prioritize paying attention to this issue despite our product managers :pray:

Amanieu (Jan 16 2020 at 18:52, on Zulip):

But after that it should be fine

nikomatsakis (Jan 16 2020 at 18:57, on Zulip):

I am reminded that I will be on vacation Feb 17

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

So that means:

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

heh

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

seems far away

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

but then...

Amanieu (Jan 16 2020 at 18:58, on Zulip):

Unless we can fit it in late Jan?

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

I'm not avail next 2 weeks

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

I guess maybe next week

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

it's a holiday :)

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

but ..

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

my partner would kill me :P

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

could shoot for another day of the week, it's just that it's hard to find those

Amanieu (Jan 16 2020 at 18:59, on Zulip):

Let's not then. A dead niko is an unproductive niko.

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

scheduling is hard :)

Kyle Strand (Jan 16 2020 at 18:59, on Zulip):

@acfoltzer any chance of trying to schedule this between your wasm meetings?

nikomatsakis (Jan 16 2020 at 19:00, on Zulip):

let's do this: try to write it up asap,

nikomatsakis (Jan 16 2020 at 19:00, on Zulip):

plan to talk feb 24, but see if we can find an earlier time, and/or conduct the discussion async

Kyle Strand (Jan 16 2020 at 19:00, on Zulip):

Conduct the discussion w/ the lang team async?

nikomatsakis (Jan 16 2020 at 19:00, on Zulip):

yeah, maybe hopeless tho

Kyle Strand (Jan 16 2020 at 19:00, on Zulip):

(I thought that was what we were scheduling for Feb)

nikomatsakis (Jan 16 2020 at 19:00, on Zulip):

it is:)

Kyle Strand (Jan 16 2020 at 19:00, on Zulip):

mm

nikomatsakis (Jan 16 2020 at 19:01, on Zulip):

I'm mostly thiking that the solution to "Scheduling hell" is async, but it only sometimes works

Kyle Strand (Jan 16 2020 at 19:01, on Zulip):

Well, to be fair, I wasn't really hoping for _consensus_ among the team from one meeting, necessarily.

nikomatsakis (Jan 16 2020 at 19:01, on Zulip):

I definitely think it'd be better if we can start the conversation earlier

nikomatsakis (Jan 16 2020 at 19:01, on Zulip):

regardless

Kyle Strand (Jan 16 2020 at 19:01, on Zulip):

But I think if we start the discussion async, then it's probably not crucial that all four of us be available for the sync lang team discussion

Kyle Strand (Jan 16 2020 at 19:01, on Zulip):

team_meeting.await

Kyle Strand (Jan 16 2020 at 19:04, on Zulip):

All right, I'm heading to lunch now. Sounds like we have, as usual, just enough of a plan to start heading in the right general direction :)

acfoltzer (Jan 16 2020 at 19:05, on Zulip):

acfoltzer any chance of trying to schedule this between your wasm meetings?

sorry, had to step away for a moment. I am at the wasm summit at Google all day on the 10th, but I don't know yet what the agenda is

acfoltzer (Jan 16 2020 at 19:05, on Zulip):

generally speaking though if the 10th works for everyone else, y'all should go for it. my motivations for being there are, as described above, mostly selfish

Kyle Strand (Jan 23 2020 at 17:41, on Zulip):

@WG-ffi-unwind Sorry all, I didn't actually make any headway on anything this week.

acfoltzer (Jan 23 2020 at 18:31, on Zulip):

same, at least in terms of direct work on this project. It looks like I'm going to be able to make it to the Rust All-Hands, which will coincidentally give me a good amount of airplane time where I hopefully be temporarily free of product concerns

acfoltzer (Jan 23 2020 at 18:31, on Zulip):

and, of course, the opportunity for high-bandwidth collaboration with anyone else on the team who will be there :slight_smile:

nikomatsakis (Jan 23 2020 at 18:39, on Zulip):

:wave: been busy, I didn't get too far either :)

nikomatsakis (Jan 23 2020 at 18:39, on Zulip):

sorry, had a call come up this week, too

nikomatsakis (Jan 23 2020 at 18:39, on Zulip):

meant to ping earlier but ..

Kyle Strand (Jan 23 2020 at 18:41, on Zulip):

I will also be at the Rust All-Hands! In fact, it will be my first time _ever_ outside the states, something I've looked forward to for...well, since I was a kid.

acfoltzer (Jan 23 2020 at 18:42, on Zulip):

oh wow, that's so exciting!

acfoltzer (Jan 23 2020 at 18:42, on Zulip):

looking forward to meeting you :)

Kyle Strand (Jan 23 2020 at 18:51, on Zulip):

Same!

Kyle Strand (Jan 29 2020 at 18:34, on Zulip):

I will be interviewing tomorrow, so I will not be able to join our weekly chat.

acfoltzer (Jan 29 2020 at 23:50, on Zulip):

good luck!

Kyle Strand (Jan 29 2020 at 23:50, on Zulip):

Thanks!

acfoltzer (Feb 06 2020 at 18:33, on Zulip):

hey folks, gotta check in very quickly this week. I haven't been doing anything on the project this week, but am trying to figure out how I can still carve out some time even with the All-Hands being canceled :cry:

acfoltzer (Feb 06 2020 at 18:34, on Zulip):

our product is starting to get into the hands of some very early alpha testers, so I'm hoping that "we want backtraces!" ends up at the top of the feedback pile, which would justify me switching gears

Kyle Strand (Feb 06 2020 at 18:38, on Zulip):

Similarly, I need to carve out some time around job-searching, which is... still taking up more of my time than I would like, because I haven't actually gotten an offer yet. :/

acfoltzer (Feb 06 2020 at 18:39, on Zulip):

... and someone just drove into our parked car out front. gotta run I guess

acfoltzer (Feb 06 2020 at 18:54, on Zulip):

okay, everything is fine, just scraped up the car a bit. I suppose I don't have much more to add, but if I can be of assistance reviewing anything please let me know

nikomatsakis (Feb 06 2020 at 22:21, on Zulip):

I've not had time to do anything

nikomatsakis (Feb 06 2020 at 22:22, on Zulip):

I still hope to put in some time to creating a doc or collating our results from before

Kyle Strand (Feb 13 2020 at 18:36, on Zulip):

@WG-ffi-unwind Starting on the 27th, the Governance group is going to start having its meetings at this time, fornightly. So we should either pick a new time for touching base, or just skip every other week.

acfoltzer (Feb 13 2020 at 18:39, on Zulip):

it seems like our activity has been slow enough that fortnightly should be fine. we can always adjust when things pick up?

Kyle Strand (Feb 13 2020 at 18:39, on Zulip):

I agree.

Kyle Strand (Feb 13 2020 at 18:40, on Zulip):

In any case, there won't be a conflict next week, which is our last scheduled meeting time before the lang team discussion.

Kyle Strand (Feb 13 2020 at 18:41, on Zulip):

On that note: I would like to get one or more blog posts published at least a week before the meeting, so that (1) potential interested parties are aware, and (2) all involved have time to ponder the issue independently prior to the meeting itself.

Kyle Strand (Feb 13 2020 at 18:42, on Zulip):

But I have made exactly zero progress towards having something publishable since last we discussed this, and it doesn't look like I'll have time today or tomorrow. I will try to allocate some hours Saturday.

nikomatsakis (Feb 14 2020 at 16:39, on Zulip):

Thanks for bringing that up, I meant to

nikomatsakis (Feb 14 2020 at 16:40, on Zulip):

@Kyle Strand I was thining I would try to allocate some time next week, so if you are able o work on saturday, that'd be great

Kyle Strand (Feb 17 2020 at 22:30, on Zulip):

@nikomatsakis Do you think we'll be able to post the blog post tomorrow (Tuesday)? I should be able to get Amanieu's suggested changes in this afternoon

Amanieu (Feb 18 2020 at 13:51, on Zulip):

I can do a second round of review on the blog post after you make your changes if you want.

Kyle Strand (Feb 19 2020 at 00:51, on Zulip):

Sorry, I thought I'd have time to make changes yesterday but didn't.

Kyle Strand (Feb 19 2020 at 03:06, on Zulip):

@Amanieu Okay, I've made changes now. It looks like we have different expectations for extern "C" in the 2-ABI strategy, but I'm not sure whose understanding is correct. I have revised the table by changing the "forced exceptions" row to specify that no destructors are assumed, and the "unforced with destructors" row to refer to forced _or_ unforced exceptions. I've revised the table entries themselves, but I am still not sure if my understanding for each of them is correct.

nikomatsakis (Feb 19 2020 at 11:06, on Zulip):

I'm taking a look at the blog post now

nikomatsakis (Feb 19 2020 at 11:29, on Zulip):

@Kyle Strand you're not around now, by any chance?

Kyle Strand (Feb 19 2020 at 15:01, on Zulip):

I hope you are traveling rather than working at some terrible hour of the night!

nikomatsakis (Feb 20 2020 at 14:08, on Zulip):

@Kyle Strand I am working very early hours =)

nikomatsakis (Feb 20 2020 at 14:08, on Zulip):

as I'm traveling

nikomatsakis (Feb 20 2020 at 14:32, on Zulip):

@Kyle Strand I meant to put in some more time into preparing notes but I'm sort of leaning towards "we should merge this asap and we can think about adding more and framing before/during meeting"

nikomatsakis (Feb 20 2020 at 14:32, on Zulip):

that said, I had some edits that felt productive

nikomatsakis (Feb 20 2020 at 14:32, on Zulip):

I just got called off on other things

nikomatsakis (Feb 20 2020 at 14:32, on Zulip):

maybe I'll push a branch to my repo

Amanieu (Feb 20 2020 at 14:52, on Zulip):

@Kyle Strand If you're too busy, I can take over finishing up the blog post.

acfoltzer (Feb 20 2020 at 18:31, on Zulip):

hey folks, just saw https://github.com/rust-lang/project-ffi-unwind/pull/21 and am taking a look now

Kyle Strand (Feb 20 2020 at 18:34, on Zulip):

@Amanieu Well, currently it seems like the most important "work item" is to resolve the points of confusion brought up in the review.

Kyle Strand (Feb 20 2020 at 18:34, on Zulip):

I'm not sure that's a "who has time" thing, exactly

Kyle Strand (Feb 20 2020 at 18:35, on Zulip):

I suppose putting Niko's bullet-list of pros and cons into blog-prose is something either of us could do. Same with transposing the table. If you have time to take a crack at either of those, that would be very helpful.

Kyle Strand (Feb 20 2020 at 18:37, on Zulip):

One concrete question I have:

[if we do not introduce a new "C unwind" API, then] panic=abort will not generate landing pads on "C" ABI functions. As long as there aren't destructors in those frames, is that sound?

Amanieu (Feb 20 2020 at 18:38, on Zulip):

It should be sound.

Kyle Strand (Feb 20 2020 at 18:38, on Zulip):

That wasn't the case Niko couldn't get to work in his branch, was it? I seem to remember the runtime aborting even when he didn't want it to

Amanieu (Feb 20 2020 at 18:39, on Zulip):

I think that may have just been an implementation issue rather than a fundamental one.

Kyle Strand (Feb 20 2020 at 19:15, on Zulip):

Okay, I'm making some changes in accordance with that.

Kyle Strand (Feb 20 2020 at 19:16, on Zulip):

Re: this discussion: https://github.com/rust-lang/project-ffi-unwind/pull/21#discussion_r381232338

Kyle Strand (Feb 20 2020 at 19:16, on Zulip):

If we have shims in extern "C" function definitions for aborting on panic-unwinding, then shouldn't we also abort on foreign exceptions to avoid UB?

Amanieu (Feb 20 2020 at 19:18, on Zulip):

We don't want to add shims to extern "C" in -Cpanic=abort. The whole point of -Cpanic=abort is that you remove all the code size overhead from unwinding.

Amanieu (Feb 20 2020 at 19:18, on Zulip):

The idea with extern "C unwind" is that you opt-in to those shims on -C panic=abort.

Kyle Strand (Feb 20 2020 at 19:22, on Zulip):

Agreed, but that discussion is about -Cpanic=unwind.

Kyle Strand (Feb 20 2020 at 19:23, on Zulip):

Niko was asking if a panic-unwind reaching an extern "C" boundary under panic=unwind should be UB.

acfoltzer (Feb 20 2020 at 19:24, on Zulip):

perhaps we could insert a shim there in debug mode only?

Amanieu (Feb 20 2020 at 19:24, on Zulip):

Oh right. Yes, we do insert a shim there.

Amanieu (Feb 20 2020 at 19:25, on Zulip):

Hmm, the problem is that we want to allow forced exceptions. So the shim would have to differentiate between them.

Kyle Strand (Feb 20 2020 at 19:26, on Zulip):

Only in proposal 2!

Amanieu (Feb 20 2020 at 19:26, on Zulip):

No, we want to always allow longjmp over extern "C" frames.

Amanieu (Feb 20 2020 at 19:26, on Zulip):

er

Amanieu (Feb 20 2020 at 19:27, on Zulip):

At least I think we do, for backward compatibility reasons.

Amanieu (Feb 20 2020 at 19:27, on Zulip):

(rlua)

Kyle Strand (Feb 20 2020 at 19:27, on Zulip):

.... reconsidering, you're correct

Kyle Strand (Feb 20 2020 at 19:27, on Zulip):

Sorry

Kyle Strand (Feb 20 2020 at 19:28, on Zulip):

So the "minimal spec" would actually be:

### Proposal 1: Introduce `"C unwind"`, minimal specification

* `"C"` ABI boundary, `panic=<any>`
  * `panic`-unwind: program aborts
  * forced unwind, no destructors: unwind behaves normally
  * forced unwind with destructors: undefined behavior
  * non-forced foreign unwind: program aborts
* `"C unwind"` ABI boundary
  * With `panic=unwind`: all types of unwinding behave normally
  * With `panic=abort`: all types of unwinding abort the program
Kyle Strand (Feb 20 2020 at 19:28, on Zulip):

Correct?

Amanieu (Feb 20 2020 at 19:32, on Zulip):

Hmm

Amanieu (Feb 20 2020 at 19:33, on Zulip):
Amanieu (Feb 20 2020 at 19:34, on Zulip):

(i need to go re-read the doc, got a link?)

Amanieu (Feb 20 2020 at 19:38, on Zulip):
### Proposal 1: Introduce `"C unwind"`, minimal specification

* `"C"` ABI boundary, `panic=<any>`
  * `panic`-unwind: program aborts
  * any unwind, no destructors: unwind behaves normally
  * any unwind, with destructors: undefined behavior
* `"C unwind"` ABI boundary
  * With `panic=unwind`: all types of unwinding behave normally
  * With `panic=abort`: all types of unwinding abort the program
Amanieu (Feb 20 2020 at 19:38, on Zulip):

Only proposal 2 treats forced unwinding and other foreign unwinding differently

Kyle Strand (Feb 20 2020 at 19:42, on Zulip):

The Paper doc?

Kyle Strand (Feb 20 2020 at 19:42, on Zulip):

https://paper.dropbox.com/doc/ffi-unwind-2020-01-13-agituL322N0qRsCbcnn7D

Amanieu (Feb 20 2020 at 19:49, on Zulip):

See my comment about for proposal 1.

Amanieu (Feb 20 2020 at 19:51, on Zulip):

For proposal 2, same as 1 but "C unwind" allows forced exceptions in -Cpanic=abort

Kyle Strand (Feb 20 2020 at 20:12, on Zulip):

Okay, I've fixed it up and transposed the table.

Kyle Strand (Feb 20 2020 at 20:12, on Zulip):

Would you mind looking at the table again?

Kyle Strand (Feb 20 2020 at 20:12, on Zulip):

I can merge the PR so you can make additional changes in a new PR if youd' like

Amanieu (Feb 20 2020 at 20:16, on Zulip):

@Kyle Strand row 1 column 3 should be "unwind" instead of "abort".

Amanieu (Feb 20 2020 at 20:17, on Zulip):

But sure, go ahead and merge. I'll send a PR with extra changes on top of yours.

Amanieu (Feb 20 2020 at 20:17, on Zulip):

In particular I want to add a list of pros/cons for each proposal.

Amanieu (Feb 20 2020 at 20:18, on Zulip):

last row column 3 should also be "unwind"

Kyle Strand (Feb 20 2020 at 20:49, on Zulip):

Okay, I've fixed those, made a few more small fixes based on other PR comments, and merged!

Kyle Strand (Feb 20 2020 at 20:50, on Zulip):

Thanks for taking on the additional work

Amanieu (Feb 21 2020 at 10:06, on Zulip):

As I'm writing the pro/cons, I'm becoming increasingly dubious about the value of proposal 2. You're only ever going to use "C unwind" if you are specifically expecting that code to throw a C++ exception. "C" is fine in all proposals if you're only expecting forced unwinds and have made sure that you don't have any destructors on the stack.

Amanieu (Feb 21 2020 at 10:07, on Zulip):

So I don't really see a reason why you would care about forced unwinds when using "C unwind": you're only ever using that ABI when calling C++ code anyways...

Amanieu (Feb 21 2020 at 10:08, on Zulip):

Or if you have a Rust function that panics that is called from C++, and want panics to propagate through the C++.

Amanieu (Feb 21 2020 at 10:08, on Zulip):

Either way, you don't really care about forced unwinds for those cases...

Amanieu (Feb 21 2020 at 10:09, on Zulip):

If you have any ideas, let me know what you think the main advantages of proposal 2 are over 1&3.

Kyle Strand (Feb 21 2020 at 15:25, on Zulip):

I suppose just that C++ code can still invoke pthread_exit, so it would be surprising if that had the effect of aborting the program depending on the compile settings.

Kyle Strand (Feb 21 2020 at 15:25, on Zulip):

But I think overall that's a good observation.

Kyle Strand (Feb 21 2020 at 15:39, on Zulip):

Since forced unwinding is supposed to be "unstoppable" per the Itanium spec, is there an issue of "compliance" from us? Do you expect people might take issue with us aborting in a scenario where Itanium says the unwind must continue even if caught?

Amanieu (Feb 21 2020 at 16:08, on Zulip):

There shouldn't be an issue. In C++ noexcept will also cause forced unwinding to abort.

Kyle Strand (Feb 21 2020 at 16:13, on Zulip):

Oh, that makes sense.

Kyle Strand (Feb 21 2020 at 23:20, on Zulip):

@Amanieu Thanks again for adding to the blog post draft. I'd suggest adding your name to the byline along with me and Niko

Kyle Strand (Feb 21 2020 at 23:21, on Zulip):

I'm wondering if we should push back the design meeting, though, if possible... @nikomatsakis you're not around to weigh in on that, are you?

Kyle Strand (Feb 21 2020 at 23:21, on Zulip):

it seems like we're not really giving anyone else in the community a chance to make time for the meeting if they're interested

Amanieu (Feb 21 2020 at 23:22, on Zulip):

Yea sorry about that I had a busy day and got to reviewing the blog post quite late.

Amanieu (Feb 21 2020 at 23:26, on Zulip):

I pushed some more fixes. If it looks good you should just merge it and push out the blog post tonight.

Amanieu (Feb 21 2020 at 23:27, on Zulip):

I think it's fine if we get the blog post out tonight, people will still be able to respond via text if they don't make it to the meeting.

Amanieu (Feb 21 2020 at 23:28, on Zulip):

I'm going to sleep now, so if you want to make more changes just merge mine first.

nikomatsakis (Feb 22 2020 at 10:47, on Zulip):

I've only lightly skimmed the above -- I'm game to push back the design meeting to another week, maybe post in #t-lang about it, @Kyle Strand? I would like to start getting feedback regardless. I've not had a chance to read the updated blog post yet.

nikomatsakis (Feb 22 2020 at 10:47, on Zulip):

I probably wont' get one until Monday

Kyle Strand (Feb 22 2020 at 16:59, on Zulip):

@Amanieu no apology necessary - most of the delay was just because I didn't have time to do much these last few weeks.

Kyle Strand (Feb 22 2020 at 17:01, on Zulip):

@nikomatsakis let's push the meeting back; perhaps another Doodle would be good?

Kyle Strand (Feb 22 2020 at 17:31, on Zulip):

I think the blog post is ready to publish once we put a new date in there.

Amanieu (Feb 22 2020 at 17:44, on Zulip):

Do we want to have a small discussion on whether to eliminate proposal 2 before publishing the blog post? Or just leave it in?

Kyle Strand (Feb 22 2020 at 17:49, on Zulip):

Hm... I think I'd prefer to leave it, at least until the lang team has a preliminary opportunity to take a look.

Kyle Strand (Feb 22 2020 at 17:51, on Zulip):

But I suppose if we decide it's strictly worse than proposal 1 then there wouldn't be any benefit in making lang team members take it into consideration

Kyle Strand (Feb 22 2020 at 17:53, on Zulip):

Here's the weird thing about proposal 1, to me: it's the only one that breaks longjmp when the compile-mode changes from panic=unwind to panic=abort. That seems somewhat surprising.

Kyle Strand (Feb 22 2020 at 17:54, on Zulip):

And, worse, it breaks only for "C unwind", and as a user I think I would be surprised to find cases where "C unwind" is strictly less "capable" than "C"

Amanieu (Feb 22 2020 at 17:56, on Zulip):

Fair enough, let's leave it in. We could add a small paragraph for it explaining the pros/cons. Pro: longjmp works with both C and C unwind. Con: it is the only proposal which treats forced unwind differently from other unwinding.

Amanieu (Feb 22 2020 at 17:56, on Zulip):

I g2g now, but I can write something up later.

Kyle Strand (Feb 22 2020 at 18:25, on Zulip):

That sounds good. I will be away from my computer for a few hours but I can probably also find time to add that if you haven't already by then

Kyle Strand (Feb 23 2020 at 21:07, on Zulip):

@Amanieu https://github.com/rust-lang/project-ffi-unwind/pull/24

BatmanAoD (Kyle Strand) (Feb 27 2020 at 18:50, on Zulip):

@WG-ffi-unwind The wg-governance meeting ran a bit long, and I stayed to chat about some topics even after it was officially wrapped. I know I brought up moving our meeting time, but we didn't actually come to a conclusion about that, did we?

BatmanAoD (Kyle Strand) (Feb 27 2020 at 18:52, on Zulip):

In any case, Erin merged the blog post, and the meeting date is officially set for this coming Monday. I haven't merged a blog.rust-lang.org post before; will the new post show up automatically soon?

acfoltzer (Feb 27 2020 at 20:48, on Zulip):

sorry, I thought we were moving to fortnightly

BatmanAoD (Kyle Strand) (Feb 27 2020 at 21:04, on Zulip):

@acfoltzer Oh, you may be right.

BatmanAoD (Kyle Strand) (Feb 27 2020 at 21:22, on Zulip):

In fact checking back over our chat logs, that was indeed the decision. I'll adjust the meeting invite

acfoltzer (Feb 27 2020 at 21:22, on Zulip):

thanks! sorry that you showed up to an empty room though :(

BatmanAoD (Kyle Strand) (Feb 27 2020 at 21:23, on Zulip):

Amanieu was around, so it wasn't _too_ lonely!

acfoltzer (Mar 05 2020 at 18:25, on Zulip):

getting my update in a bit early before a conflicting meeting: my end of things this fortnight was mostly getting calendaring mixed up :upside_down:

acfoltzer (Mar 05 2020 at 18:26, on Zulip):

I'm really grateful to the work that y'all are doing to get a meeting together, though, and look forward to participating when we have a new time nailed down

BatmanAoD (Kyle Strand) (Mar 05 2020 at 18:35, on Zulip):

@WG-ffi-unwind Biweekly (fortnightly) check-in! Given the conversation above, I think pretty much everyone in that Zulip group already knows our status, but:

The main update is that we need to reschedule the meeting with the lang team.Also, Amanieu and I met and decided to eliminate one of the three proposals, narrowing us down to two.

@Amanieu you're not part of the @WG-ffi-unwind Zulip group. Would you like to be added? @gnzlbg same question.

BatmanAoD (Kyle Strand) (Mar 05 2020 at 18:36, on Zulip):

Once we've confirmed a date (I'm guessing the 16th) for the meeting with the Lang team, I think it would make sense to post in #t-lang again.

nikomatsakis (Mar 05 2020 at 18:37, on Zulip):

hey all

Amanieu (Mar 05 2020 at 18:59, on Zulip):

@BatmanAoD (Kyle Strand) Sure, add me to the group.

acfoltzer (Mar 19 2020 at 17:30, on Zulip):

hey folks, I'm on PTO today but just wanted to drop in to say thank you for all the great discussion both synchronously on Monday and on here since. I'll be back at work tomorrow afternoon and will be writing up more of my thoughts about how I'm finding myself leaning

BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:32, on Zulip):

@WG-ffi-unwind Weekly check-in! It seems the next order of business is for the lang team to make a decision on the proposals we've set out; I think Niko can provide some guidance on how much (if any) this group is expected to participate in that process.

Amanieu (Mar 19 2020 at 17:33, on Zulip):

Update from me: I'm working on making catch_unwind catch and rethrow foreign exceptions. It's actually not as complicated as I thought it would be.

nikomatsakis (Mar 19 2020 at 17:34, on Zulip):

Well, my take is that i'd love to see some the "current status" thoughts from each person -- @acfoltzer kind of provided their take, but I'm not sure about you, @BatmanAoD (Kyle Strand). And I saw @Amanieu wrote something like "I favor proposal 2" but I don't know if I know which one that is (I think "C unwind") and I'd be curious what their reasoning is.

nikomatsakis (Mar 19 2020 at 17:34, on Zulip):

Amanieu said:

Update from me: I'm working on making catch_unwind catch and rethrow foreign exceptions. It's actually not as complicated as I thought it would be.

interesting!

nikomatsakis (Mar 19 2020 at 17:34, on Zulip):

I'm curious also how you think that should interact with forced exceptions

BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:35, on Zulip):

As long as the exception is rethrown, my understanding is that catching forced exceptions should work just like catching unforced exceptions.

BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:35, on Zulip):

(By "my understanding" I mean "I think this is what LLVM/C++/etc expect".)

nikomatsakis (Mar 19 2020 at 17:36, on Zulip):

I guess I don't know what catch_unwind "catching and rethrowing" foreign exceptions really means

nikomatsakis (Mar 19 2020 at 17:36, on Zulip):

like, I don't know what interface is being expsed to Rust users

nikomatsakis (Mar 19 2020 at 17:36, on Zulip):

I'm thinking about how C++ lets you catch "any exception", but doing so w/o rethrowing seems to be a kind of bug

nikomatsakis (Mar 19 2020 at 17:37, on Zulip):

(because you can intercept forced exceptions and fail to rethrow)

BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:40, on Zulip):

Same. I was actually thinking that there could be a better interface for invoking FFI code and catching foreign exceptions. Perhaps something like:

fn try_ffi(entrypoint: extern "C" fn(), exception_handler: FnOnce(ForeignException) -> ContinueUnwind)

...where ForeignException is some opaque type, and ContinueUnwind is some type representing what the runtime should do after the handler has been invoked. (This is...sketchy. I haven't thought much about it yet.)

Amanieu (Mar 19 2020 at 17:42, on Zulip):

Basically catch_unwind returns a Box<ForeignException> and resume_unwind magically turns that back into the original exception.

BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:42, on Zulip):

Reviewing some older threads: one need, it seems, is the ability to re-throw the foreign exception from a different thread. Correct?

nikomatsakis (Mar 19 2020 at 17:45, on Zulip):

Amanieu said:

Basically catch_unwind returns a Box<ForeignException> and resume_unwind magically turns that back into the original exception.

ok, so nothing kind of forces you to do that "resume"

Amanieu (Mar 19 2020 at 17:45, on Zulip):

Yes, sending the exception to another thread will work fine.

Amanieu (Mar 19 2020 at 17:47, on Zulip):

There is no special handling for forced exceptions at the moment, but I can easily change catch_unwind to ignore foreign exceptions if necessary.

nikomatsakis (Mar 19 2020 at 17:47, on Zulip):

I'm not sure if it should ignore them, seems maybe bad

nikomatsakis (Mar 19 2020 at 17:48, on Zulip):

(But anyway that's something that can be hammered out at some point)

nikomatsakis (Mar 26 2020 at 18:56, on Zulip):

@acfoltzer were you ever able to write up a comment?

acfoltzer (Apr 02 2020 at 17:21, on Zulip):

nikomatsakis said:

acfoltzer were you ever able to write up a comment?

gah, Zulip signed me out in the background, I missed this :disappointed:

acfoltzer (Apr 02 2020 at 17:21, on Zulip):

that's what I get for turning off all the email notifications I can

acfoltzer (Apr 02 2020 at 17:43, on Zulip):

It sounds like the horse is already out of the barn, which I am fine with, but just for posterity's sake I have three reasons for favoring a single "C" ABI, perhaps with a #[nounwind] attribute for optimization:

BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:49, on Zulip):

Hm. I do find those reasons compelling.

I also wonder about @nikomatsakis's "Rust values" point. I agree that we don't want panic=abort to introduce UB, but it's almost stranger to me that we'd have UB with panic=unwind in some cases.

BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:49, on Zulip):

I.e., I would generally expect that one of Rust's values is "do the right thing by default".

BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:50, on Zulip):

And that another is "UB is usually not 'the right thing'".

centril (Apr 02 2020 at 17:52, on Zulip):

Dodging the questions of subtyping and variance between "C" and "C unwind": I agree that making these invariant is the right call for now since we can always wrap one in the other, but this is going to be a source of friction for callback APIs

Adding subtyping between types is *extremely unlikely* as an addition to Rust. Coercions is at most what we would add for convenience, and then shims might be introduced automatically

BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:54, on Zulip):

But both of those values are, I think, more of my own personal desires than ones espoused by the Rust community at large. It's not clear that they'd be shared more broadly.

BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:54, on Zulip):

@centril That's why Adam is saying that introducing a new ABI is problematic.

centril (Apr 02 2020 at 17:55, on Zulip):

@acfoltzer by subtyping do you include coercions?

centril (Apr 02 2020 at 17:56, on Zulip):

I ask because there's regular confusion between the two concepts

centril (Apr 02 2020 at 17:56, on Zulip):

Many don't actually mean subtyping when they use the term

centril (Apr 02 2020 at 18:00, on Zulip):

@BatmanAoD (Kyle Strand) I don't think the lack of subtyping would add notable friction; most of the time you're dealing with top level coercions and not e.g., Vec<extern "C" fn()> where the question of subtyping would come into play

centril (Apr 02 2020 at 18:01, on Zulip):

&'lifetime extern "C" fn() would also be an example, but that seems like an unusual type

acfoltzer (Apr 02 2020 at 18:02, on Zulip):

coercions would suffice as well, but it'd still be complicated to work out which coercions are valid where, because functions are contravariant

acfoltzer (Apr 02 2020 at 18:03, on Zulip):

I say subtyping because that's how I think about it from my academic PL background :)

centril (Apr 02 2020 at 18:04, on Zulip):

@acfoltzer that's surprising, precisely because from a type theoretic perspective (at least that which I know of) coercions are understood as something else

acfoltzer (Apr 02 2020 at 18:05, on Zulip):

for this topic I'm leaning on my knowledge of the multi-language semantics literature, contracts, blame calculus, etc

centril (Apr 02 2020 at 18:06, on Zulip):

To my knowledge we have generic infrastructure for handling contravariance and such

acfoltzer (Apr 02 2020 at 18:06, on Zulip):

I'm less of a type theorist :)

centril (Apr 02 2020 at 18:06, on Zulip):

(with respect to coercions)

acfoltzer (Apr 02 2020 at 18:08, on Zulip):

I should probably re-read https://doc.rust-lang.org/nomicon/coercions.html

BatmanAoD (Kyle Strand) (Apr 02 2020 at 18:12, on Zulip):

In any case: for now, I am drafting a PR for "C unwind". I think we'll have time before submitting it as a PR to re-open discussion with the lang team; @nikomatsakis should Adam share his bullet points above in #t-lang ?

centril (Apr 02 2020 at 18:13, on Zulip):

@acfoltzer for contravariance we can take unsafe fn's lead:

fn foo() {
    let a: fn() = loop {};
    let b: unsafe fn() = a; // OK.

    let c: fn(fn()) = loop {};
    let d: fn(unsafe fn()) = c; // ERROR.
}
acfoltzer (Apr 02 2020 at 18:15, on Zulip):

got it, that makes sense

centril (Apr 02 2020 at 18:22, on Zulip):

(So the coercion extern "C" fn() to extern "C unwind" fn() would OK and doesn't need a shim; the reverse coercion would also be OK but would need a shim to abort unless perhaps with -C panic=abort.)

nikomatsakis (Apr 03 2020 at 19:15, on Zulip):

BatmanAoD (Kyle Strand) said:

In any case: for now, I am drafting a PR for "C unwind". I think we'll have time before submitting it as a PR to re-open discussion with the lang team; nikomatsakis should Adam share his bullet points above in #t-lang ?

I found them informative.

nikomatsakis (Apr 03 2020 at 19:15, on Zulip):

but I don't know that we have to post them in t-lang necessarily

nikomatsakis (Apr 03 2020 at 19:16, on Zulip):

acfoltzer said:

It sounds like the horse is already out of the barn, which I am fine with, but just for posterity's sake I have three reasons for favoring a single "C" ABI, perhaps with a #[nounwind] attribute for optimization:

@T-lang -- regarding the "C" vs "C unwind" question, these are the points that @acfoltzer submitted :point_up:

Josh Triplett (Apr 03 2020 at 19:17, on Zulip):

Would unifying them lead to a substantial degree of additional code size by default?

nikomatsakis (Apr 03 2020 at 19:20, on Zulip):

If we unified them, it would mean that:

nikomatsakis (Apr 03 2020 at 19:20, on Zulip):

However, the downside is that you may have some library that interacts with c++ code where that C++ code throws an exception

nikomatsakis (Apr 03 2020 at 19:20, on Zulip):

This Rust library is UB to use with panic=abort

nikomatsakis (Apr 03 2020 at 19:21, on Zulip):

But you won't really get any kind of "warning" about that, we don't really have a way to "signal that" now

nikomatsakis (Apr 03 2020 at 19:21, on Zulip):

If otoh that library were using "C unwind" as its abi (thus declaring its intention to interact with foreign exceptions), we could at least give you a hard error

nikomatsakis (Apr 03 2020 at 19:21, on Zulip):

On the other other hand, we could catch and abort with unwinding and panic=abort in debug code without any real problem, so maybe you'd notice these problems relatively early.

nikomatsakis (Apr 03 2020 at 19:22, on Zulip):

That's why, to me, this kind of comes down to how much we should be pushing people to write code that interoperates with panic=abort and panic=unwind, which was the thing I emphasized in my earlier comment.

nikomatsakis (Apr 03 2020 at 19:23, on Zulip):

But I think another key question is how hard you think it is to explain to people that they have to use "C unwind" if they expect foreign exceptions to propagate across the boundary. That doesn't seem too hard to me, but I may be 'too close' to see the cognitive cost.

BatmanAoD (Kyle Strand) (Apr 03 2020 at 20:00, on Zulip):

nikomatsakis said:

If otoh that library were using "C unwind" as its abi (thus declaring its intention to interact with foreign exceptions), we could at least give you a hard error

To clarify, this would be a runtime error (abort)

nikomatsakis (Apr 06 2020 at 21:52, on Zulip):

Yes, correct, sorry.

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

@WG-ffi-unwind Weekly check-in!

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

Niko has written some decently extensive comments on the RFC draft, but I haven't addressed them yet. I should be able to get to them this weekend, I think.

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

Nothing else to report at this time.

Amanieu (Apr 16 2020 at 17:31, on Zulip):

At this point the only task left for this WG is writing the RFC. So I don't think there is anything else to report.

acfoltzer (Apr 16 2020 at 17:31, on Zulip):

I have the RFC draft on my github review queue, but that queue is currently growing faster than I can get through :upside_down:

acfoltzer (Apr 16 2020 at 17:32, on Zulip):

I would like to take a look but am turbo-busy at work currently, so don't hold up the merge if I am not able to make the time

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:32, on Zulip):

Okay, understandable.

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:33, on Zulip):

Are you okay with moving forward under the assumption that we'll introduce "C unwind"?

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:33, on Zulip):

That's the main thing we might need your input on

acfoltzer (Apr 16 2020 at 17:33, on Zulip):

I feel very comfortable that my perspective has been incorporated so far, and yes, okay with "C unwind"

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:33, on Zulip):

:+1:

acfoltzer (Apr 16 2020 at 17:33, on Zulip):

I still have a preference for "C" but not a deeply held one

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:33, on Zulip):

I think I'm in a similar boat

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:34, on Zulip):

Fortunately, I think most of the RFC text will be similar regardless of which we pick

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:34, on Zulip):

But I think when the RFC is ready to submit, we should maybe discuss one last time, so that when we submit it as a PR to the actual rfcs repo, we are fully committed to "C unwind" (or not)

acfoltzer (Apr 16 2020 at 17:35, on Zulip):

I should say, my preference for "C" is less strong than my desire for things to move forward either way. from a Fastly perspective either solution will meet our needs

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:36, on Zulip):

I think it's probably the case that both solutions will meet everyone's _needs_ but not necessarily everyone's "ideal case"

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:36, on Zulip):

I do think defaults matter, and overall Rust has done such an impressive job of having good defaults that I'd hate to contribute a new case where the default seems wrong!

BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:37, on Zulip):

But I also think that "the default seems wrong" is probably not something we'll know without the benefit of hindsight from many people using the feature over time

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

Well, unless @nikomatsakis has anything to add, I think we can call that a wrap

nikomatsakis (Apr 16 2020 at 18:39, on Zulip):

Sorry, I was distracted today

BatmanAoD (Kyle Strand) (Apr 16 2020 at 18:55, on Zulip):

No problem.

acfoltzer (Apr 30 2020 at 17:21, on Zulip):

hey y'all, I have a conflict for our usual 10:30 time today, but I was able to offer some (very minor) comments on the RFC just now. I am very impressed by and grateful for the work that y'all have done on this. it really will make a big difference for our work on Lucet

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

I'm around was going to go take a fresh look

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

I do have a bit of a "ok let's just do this thing" feeling

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

i.e., even if there might be ways to improve the text...not clear how much it's worth it, as long as we all agree unambiguously on the end result

acfoltzer (Apr 30 2020 at 17:25, on Zulip):

I was going to write up my main higher-level concern, but I see that there's already a discussion underway in #project-ffi-unwind > Revised RFC on the same topic. I worry that there's a fair amount of prerequisite knowledge required to grasp the distinction between forced and non-forced unwinding. But I also am leaning toward Niko's "let's just do this thing" assessment

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

I would like it that people who read it .. yeah .. understand well what it means

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

but also some of that enery can go into writing up docs for the reference

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

I think the specification is going to ultimately be the same; the current RFC already does state that longjmp and pthread_exit are treated the same regardless of whether forced unwinding is involved or not. I am game to change it around, but I think the entire framing would need to change from "unwinding is now allowed, with 'C unwind'" to "non-local control flow involving FFI".

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

The 'unwinding' framing matches the name of the new ABI string pretty well, which I think is a plus.

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

To me, it seems like anyone who wants to be doing cross-language unwinding is probably going to know the word "unwinding", and also know that "panic" in Rust and "exceptions" in C++ are both forms of "unwinding". They may or may not also know about "forced unwinding", but if they click through to see previous discussions and/or the Inside Rust blog post, they'll _definitely_ see "forced unwinding". So I think it's good to at least mention it, and then say "nope, this doesn't count."

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

@WG-ffi-unwind I think everyone interested in the weekly sync-up may already be here, but just in case, here's your notification!

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

I'm checking out your PR locally

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

I was curious to read it again and experiment a bit

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

I'm not sure I follow the idea that it will require massive rewrites

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

I don't mean that the entire thing would need to be thrown out; it's more that the framing in terms of "unwinding" seems incorrect if we want to specify the behavior in terms of things-that-cause-non-local-control-flow.

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

re-reading it, I think it seems "pretty ok",

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

although I find the phrase "unforced foreign unwind" (sometimes we say "non-forced foreign unwind"...) kind of confusing

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

"nonunforced"?

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

Please tell me I didn't write that :laughing:

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

no, you wrote unforced and non-forced

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

ah

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

both of which are confounding to me :)

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

i.e., I know what it means

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

"unforced error"

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

but my brain has to sit and decode it

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

like in Tennis

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

I would rather just say "foreign unwind"

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

this is a flaw in the terminology, I guess, which suggested that foreign unwind is the superset of the two

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

when that is just not a useful concept, since they share nothing in common in terms of our behavior

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

it'd be better to just call it "forced unwind" in this way :)

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

Yeah, I think we can just say in the "forced unwinding" section something like "throughout this RFC, unwinding does not refer to forced-unwinding, unless otherwise specified"

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

I'd be in favor of that

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

I think we should call it

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

The more I think about it, the forced-unwinding section is mostly a disclaimer: "we don't actually support this in the same way that we support other unwinding"

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

Whereas when I wrote that section originally (and the blog post), I was thinking more "here's some necessary context for the specification of the new behavior"

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

Not to toot my own horn, but taking the forced-unwind columns out of the table entirely was a good decision, I think.

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

I will review, and try to limit discussion of forced-unwinding-as-such to the "forced unwind" section, which I will then review with my newfound "this is a disclaimer" mindset.

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

Wherever else forced unwinding shows up, I'll make sure it's more of a footnote - "see the force unwind disclaimer"

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

I'm currently editing the motivation a bit

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

do you mind if I push some commits to your branch?

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

I'll ping you when I do

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

I'm trying to address my point about adding in our design constriants

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

@BatmanAoD (Kyle Strand) :point_up:

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

I think one remaining interesting point is what to say about foreign exceptions propagating through Rust frames

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:01, on Zulip):

I do not mind

nikomatsakis (Apr 30 2020 at 18:07, on Zulip):

@BatmanAoD (Kyle Strand) take a look!

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

Looks good, though shouldn't the 'analysis of key design goals' subsection go in the 'rationale' section?

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:12, on Zulip):

Also, I thought it would be good to call out that this RFC was drafted by the project group, so I added that to the "header" material at the top. What do you think?

nikomatsakis (Apr 30 2020 at 18:13, on Zulip):

BatmanAoD (Kyle Strand) said:

Looks good, though shouldn't the 'analysis of key design goals' subsection go in the 'rationale' section?

move it to wherever you feel best

nikomatsakis (Apr 30 2020 at 18:13, on Zulip):

one thing though

nikomatsakis (Apr 30 2020 at 18:13, on Zulip):

I think we should a "key goal" to be enabling longjmp-based error handling

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

I forgot that I think

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

I think that kind of covers the "three scenarios" we care about?

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:22, on Zulip):

Well, I noticed that I already had a very similar bullet-point list, based on the Inside Rust post's list.

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:23, on Zulip):

One that was missing from your list, which I've now incorporated, is keeping the libc API stable.

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:23, on Zulip):

That's sort of the same requirement, is it? Though it should be rephrased to explain why it's relevant.

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:23, on Zulip):

Hmmmm never mind, sorry, that's b/c of pthread_exit, not longjmp

nikomatsakis (Apr 30 2020 at 18:26, on Zulip):

regardless it's ok to say twice :)

nikomatsakis (Apr 30 2020 at 18:26, on Zulip):

but I do feel it's distinct

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:26, on Zulip):

Oh, I was thinking that if they were the same issue, it could be rephrased to focus on longjmp instead of libc

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:26, on Zulip):

but they are not the same, so I'll introduce a new bullet.

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:40, on Zulip):

I can't find it now, but I left a comment in response to one of yours about the "inert" terminology. I am starting to lean towards adopting such a term, though as I mentioned I'm not sold on "inert" specifically.

BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:40, on Zulip):

I think I suggested "disposable"?

nikomatsakis (May 01 2020 at 20:49, on Zulip):

BatmanAoD (Kyle Strand) said:

I can't find it now, but I left a comment in response to one of yours about the "inert" terminology. I am starting to lean towards adopting such a term, though as I mentioned I'm not sold on "inert" specifically.

I did feel it was missing, @BatmanAoD (Kyle Strand)

nikomatsakis (May 01 2020 at 20:49, on Zulip):

I refrained from suggesting it, but it felt like a "concept" that arose a few times

nikomatsakis (May 01 2020 at 20:49, on Zulip):

and sometimes we were consistent with saying "or catch-unwind"

nikomatsakis (May 01 2020 at 20:49, on Zulip):

and sometimes we just talked about destructors

nikomatsakis (May 01 2020 at 20:49, on Zulip):

an option might be to .. steal a term like POD?

nikomatsakis (May 01 2020 at 20:49, on Zulip):

that's probably confusing

BatmanAoD (Kyle Strand) (May 01 2020 at 21:21, on Zulip):

I think I'd rather just create a new term, as long as it's somewhat intuitive. Now that I think about it, though, an actual precise definition is a little bit difficult, because there are edge cases where frames with destructors or catch_unwind would still be "disposable":

...etc. One way to define it might be to say "a panic would not cause any non-trivial code to execute", where "non-trivial" means... something about side effects, I guess.

nikomatsakis (May 01 2020 at 21:51, on Zulip):

I think we can wave our hands and say "destructors in scope"

nikomatsakis (May 01 2020 at 21:51, on Zulip):

it's good enough for now

nikomatsakis (May 01 2020 at 21:52, on Zulip):

where "destructors in scope" means that there is a live (non-moved) value whose type has a destructor, or something like that (the notion in the compiler is "drop glue", but I don't know what term we use in the reference)

simulacrum (May 01 2020 at 22:39, on Zulip):

at a high level, catch_unwind is just fancy drop glue :)

it's a bit unfortunate we don't have a nice term here though I think

BatmanAoD (Kyle Strand) (May 01 2020 at 22:59, on Zulip):

Do either of you know why it's called "glue"?

simulacrum (May 02 2020 at 00:34, on Zulip):

hm, not entirely, but probably because it's "glue code" related to drop :)
There's references to it as early as 2014 in the rfcs repo, for example

nikomatsakis (May 02 2020 at 10:25, on Zulip):

simulacrum said:

it's a bit unfortunate we don't have a nice term here though I think

I know

nikomatsakis (May 02 2020 at 10:26, on Zulip):

the term glue code predates me, but it was used for any automatically generated code that walked the type structure

simulacrum (May 02 2020 at 11:48, on Zulip):

technically it's "landing pads" I think, at least on MSVC? But we could co-opt the term to other platforms. Though that could be confusing in and of itself.

simulacrum (May 02 2020 at 11:49, on Zulip):

AIUI, we can't even really say "code executes during unwinding", because at least at a high level DWARF unwinding is capable of executing essentially arbitrary code (not machine-level, but DWARF level)

Amanieu (May 02 2020 at 12:31, on Zulip):

Also because of drop flags we may still have landing pads while not have any destructors to execute.

Amanieu (May 02 2020 at 12:31, on Zulip):
let x;
if (foo)
    x = String::new("foo");
longjmp();
Amanieu (May 02 2020 at 12:33, on Zulip):

Is this allowed if foo is false? Technically no destructors run, but we still have to run code to check if x has been initialized.

nikomatsakis (May 04 2020 at 14:10, on Zulip):

interesting question, really narrowing down just when it is legal is an interesting question. In practice it seems like it'd be fine to skip the landing pad in that example, but it's probably UB from LLVM's perspective

BatmanAoD (Kyle Strand) (May 04 2020 at 14:38, on Zulip):

Really? I would not expect LLVM to make that UB...

Amanieu (May 04 2020 at 16:52, on Zulip):

I don't think LLVM will make that UB either. And I agree that it's fine to skip the landing pad in this case.

BatmanAoD (Kyle Strand) (May 14 2020 at 17:34, on Zulip):

@WG-ffi-unwind Biweekly check-in!

BatmanAoD (Kyle Strand) (May 14 2020 at 17:35, on Zulip):

As I said in #project-ffi-unwind > posting the RFc , there are still a few TODOs left in the RFC. I am probably still the best person to write these up, but the 'TODO' comments in the draft should be sufficient for any interested parties to lend a hand.

acfoltzer (May 14 2020 at 17:35, on Zulip):

:wave: hey, no updates from me this week. currently double-booked with the Bytecode Alliance meeting. I don't see any review requests on Github anymore, but let me know if there's more I can do to help

nikomatsakis (May 14 2020 at 17:38, on Zulip):

No real updates, I'd like to post the RFC

Last update: May 27 2020 at 23:10UTC