Stream: project-ffi-unwind

Topic: weekly meeting


view this post on Zulip nikomatsakis (Oct 31 2019 at 17:36):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:38):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:38):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:38):

so where are we at

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:39):

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

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

Sounds good!

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:42):

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

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

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)

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:42):

I haven't revisited since my last round of comments

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:42):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:42):

I should check

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

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:

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

No, I haven't made any modifications since then

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:43):

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?

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

But those were the only two outstanding concerns

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

yep

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:43):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:44):

"catching foreign exceptions", that topic

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:44):

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

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

Yes

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:46):

oh I see there have been some new additions as well

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:46):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:46):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:47):

I guess longjmp is such an example :)

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:47):

(at least on MSVC)

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

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:48):

I do not mean to read any threads :)

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

Perfect!

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:49):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:49):

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.

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

Yes

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:49):

I am struggling with this statement :)

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:49):

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

view this post on Zulip acfoltzer (Oct 31 2019 at 17:49):

hey, sorry I'm late. catching up now

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:49):

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

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

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

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

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

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

and

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:50):

okI think the argument is:

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:51):

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

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

Yes

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:51):

that's an interesting argument

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

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

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

"detrimental" may be too strong

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

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

view this post on Zulip acfoltzer (Oct 31 2019 at 17:54):

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!

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:54):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:55):

but I see the point

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:55):

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?

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

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

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

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.

view this post on Zulip acfoltzer (Oct 31 2019 at 17:57):

sandbox in what sense, here?

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

Sandboxing unwinding ops to prevent them from escaping

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:57):

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

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

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:57):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:57):

it is most definitely not sandboxing it

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:58):

it doesn't seem that different frm any other type

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

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)

view this post on Zulip acfoltzer (Oct 31 2019 at 17:58):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:59):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:59):

it seems like a key point

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:59):

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

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

True.

view this post on Zulip nikomatsakis (Oct 31 2019 at 17:59):

at least what I see as the strongest argument

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:00):

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.

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:00):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:00):

for code that otherwise worked

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:00):

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)

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:00):

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

view this post on Zulip acfoltzer (Oct 31 2019 at 18:01):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:01):

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)

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:02):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:02):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:02):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:02):

instead of aborting

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:02):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:02):

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

it would just be UB al the time

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:02):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:03):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:04):

@gnzlbg are you around?

view this post on Zulip acfoltzer (Oct 31 2019 at 18:04):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:04):

@nikomatsakis more or less

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:04):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:04):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:04):

that is an alternative though

view this post on Zulip gnzlbg (Oct 31 2019 at 18:05):

I haven't read this thread

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:05):

@gnzlbg what I specifically wanted to ask you is

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:05):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:05):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:05):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:05):

aah, sorry

view this post on Zulip gnzlbg (Oct 31 2019 at 18:06):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:06):

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?

view this post on Zulip gnzlbg (Oct 31 2019 at 18:06):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:06):

@gnzlbg presumably longjmp also falls into this category?

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:06):

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

woah wait hold up :)

view this post on Zulip gnzlbg (Oct 31 2019 at 18:06):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:06):

that's a fairly broad category

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:06):

ok, that's interesting

view this post on Zulip gnzlbg (Oct 31 2019 at 18:07):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:07):

e.g. printf can be a cancellation point

view this post on Zulip gnzlbg (Oct 31 2019 at 18:07):

basically it works like a garbage collector would in say Java

view this post on Zulip gnzlbg (Oct 31 2019 at 18:08):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:08):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:08):

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"

view this post on Zulip acfoltzer (Oct 31 2019 at 18:09):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:10):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:10):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:10):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:11):

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

view this post on Zulip centril (Oct 31 2019 at 18:11):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:11):

@gnzlbg thanks I will add those details to the hackmd

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:11):

so I think i've revised my opinion

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:11):

I used to think this was open-and-shut

view this post on Zulip centril (Oct 31 2019 at 18:11):

There; the "RFC" is in FCP now

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:12):

but now I think that it's unclear

view this post on Zulip gnzlbg (Oct 31 2019 at 18:12):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:13):

yes

view this post on Zulip gnzlbg (Oct 31 2019 at 18:13):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:13):

that's kind of the status quo right now

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:13):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:13):

right, I think that is one of the options

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:14):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:14):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:14):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:14):

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:

view this post on Zulip gnzlbg (Oct 31 2019 at 18:14):

might be a libs-team issue

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:14):

I feel like it merits a more focused discussion

view this post on Zulip centril (Oct 31 2019 at 18:14):

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

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:14):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:14):

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

view this post on Zulip centril (Oct 31 2019 at 18:14):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:15):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:15):

which is kind of a "worse case' :)

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:16):

might be a libs-team issue

actually it occurs to me that

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:16):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:16):

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

view this post on Zulip centril (Oct 31 2019 at 18:16):

@nikomatsakis huh?

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:17):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:17):

in a backwards compatible way

view this post on Zulip gnzlbg (Oct 31 2019 at 18:17):

yes, that was also another possible design

view this post on Zulip centril (Oct 31 2019 at 18:17):

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

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

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

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

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

Noted, but that's not universal!

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

yes but also

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

it's not just about libc back-compat

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:19):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:19):

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

view this post on Zulip centril (Oct 31 2019 at 18:19):

@nikomatsakis btw, 10 min to pre-triage

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:19):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:19):

you could also argue for the opposite default

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:20):

which is where @Amanieu started

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:20):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:21):

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

view this post on Zulip centril (Oct 31 2019 at 18:22):

@Kyle Strand "the shim" ?

view this post on Zulip centril (Oct 31 2019 at 18:22):

the abort on unwind shim?

view this post on Zulip centril (Oct 31 2019 at 18:22):

or some other?

view this post on Zulip centril (Oct 31 2019 at 18:22):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:23):

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

view this post on Zulip centril (Oct 31 2019 at 18:23):

@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

view this post on Zulip centril (Oct 31 2019 at 18:24):

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

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

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?

view this post on Zulip centril (Oct 31 2019 at 18:25):

I don't believe so

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:26):

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

view this post on Zulip centril (Oct 31 2019 at 18:26):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:26):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:26):

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:

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:27):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:27):

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

view this post on Zulip centril (Oct 31 2019 at 18:27):

that seems inconsistent yes

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 31 2019 at 18:28):

Okay, glad I remembered correctly :smile:

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:28):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:28):

It also depends a lot on the defaults.

view this post on Zulip centril (Oct 31 2019 at 18:28):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:29):

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?

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:29):

it seems eminently measurable

view this post on Zulip centril (Oct 31 2019 at 18:30):

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

view this post on Zulip nikomatsakis (Oct 31 2019 at 18:30):

yes, I know.

view this post on Zulip gnzlbg (Oct 31 2019 at 18:33):

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

view this post on Zulip gnzlbg (Oct 31 2019 at 18:33):

but that's more a syntactic issue

view this post on Zulip Amanieu (Oct 31 2019 at 19:07):

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.

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

maybe, that was an unresolved question last time

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

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

view this post on Zulip acfoltzer (Nov 07 2019 at 18:27):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:33):

:wave:

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:33):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:34):

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

view this post on Zulip acfoltzer (Nov 07 2019 at 18:49):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:51):

https://hackmd.io/ymsEL6OpR6OSMoFr1As1rw

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:52):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:52):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:52):

Let me take 10 minutes to see...

view this post on Zulip acfoltzer (Nov 07 2019 at 18:52):

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

view this post on Zulip acfoltzer (Nov 07 2019 at 18:53):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:54):

what I didn't like about this framing

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:54):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:55):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:55):

I'm creating a second hackmd to play around

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:58):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 18:58):

I know that @gnzlbg had some smaller measurements

view this post on Zulip gnzlbg (Nov 07 2019 at 19:02):

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.

view this post on Zulip gnzlbg (Nov 07 2019 at 19:03):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:03):

I agree

view this post on Zulip Taylor Cramer (Nov 07 2019 at 19:04):

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

view this post on Zulip gnzlbg (Nov 07 2019 at 19:04):

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

view this post on Zulip Taylor Cramer (Nov 07 2019 at 19:04):

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

view this post on Zulip Taylor Cramer (Nov 07 2019 at 19:05):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:06):

yes, it seems like a perfect case to measure

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:06):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:06):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:06):

(I think it's an upper bound?)

view this post on Zulip acfoltzer (Nov 07 2019 at 19:09):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 07 2019 at 19:17):

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.

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:19):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:20):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:20):

"the rest is details"

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:20):

I think we've kind of covered the space

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:20):

in terms of considerations

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:29):

ok so I've been working on this alternate form

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:30):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:30):

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

view this post on Zulip nikomatsakis (Nov 07 2019 at 19:30):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 07 2019 at 19:46):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 07 2019 at 19:47):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:28):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:44):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:45):

Want to sync up now?

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:47):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:47):

At this point I still really want to see some data

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:47):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:47):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:47):

Not sure how hard that will be

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:47):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:48):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:48):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:48):

er, "Inside Rust"

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:48):

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?

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:51):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:52):

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.

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:52):

:/

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:52):

Oh please never apologize for that :)

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:52):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:52):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:52):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:53):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:54):

Are you interested in trying to write said blog post?

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:55):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:55):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:56):

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.

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:56):

one thing -- we do now have the two documents

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:56):

I would prefer to deprecate the first one :)

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:57):

the two HackMDs?

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:57):

at least two, but yeah

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:57):

the one centril commented on is the older one

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:57):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:57):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:57):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:57):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:58):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:58):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:58):

Newer document: "meaning of the C abi"

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 18:58):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:59):

I think what could be improved in this doc a bit

view this post on Zulip nikomatsakis (Nov 14 2019 at 18:59):

hmm have to think about it

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:00):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:00):

maybe I should move them to the front :)

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:00):

and trying to tell different "stories"--

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:00):

anyway

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:00):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:01):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:01):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:01):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:01):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:04):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:04):

They're at least tightly coupled.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:04):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:05):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:08):

Or, to remove the word "sandbox" entirely:

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:09):

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:

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:11):

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

I agree

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:11):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:11):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:12):

but I do think that updating the repo is maybe good

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:12):

in particular, our roadmap seems wrong

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:12):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:12):

but it seems is not

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:12):

and we've not updated that

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:12):

("figuring out the overall direction")

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:18):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:18):

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.

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:21):

Yes.

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:21):

I do think that's a super good goal

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:21):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:21):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:21):

A wiki is a plausible structure here

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:21):

(We could even use GH's wikis)

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:22):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:22):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:22):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:22):

Yes

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:22):

Hmmm

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:22):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:23):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:23):

and I am deeply concerned about the way our current practices

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:23):

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.

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:23):

leave us with a very confusing "design trail"

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:23):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:23):

Yes!

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:23):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:23):

the wiki page would link to zulip topics

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:23):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:24):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:24):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:24):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:24):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:24):

well, you could just link to the topics in general

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:24):

and not try to link to specific messages within

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:24):

like "this was discussed here"

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:24):

I'm imagining like

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:25):

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:

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:25):

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

view this post on Zulip nikomatsakis (Nov 14 2019 at 19:26):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:28):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:44):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:44):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:44):

If indeed it's even necessary.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 19:48):

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.

view this post on Zulip centril (Nov 14 2019 at 22:36):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 18 2019 at 00:08):

@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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 18 2019 at 01:43):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 18 2019 at 01:49):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 18 2019 at 01:52):

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?

view this post on Zulip nikomatsakis (Nov 18 2019 at 11:02):

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

view this post on Zulip nikomatsakis (Nov 18 2019 at 11:02):

I think either could be fine

view this post on Zulip nikomatsakis (Nov 18 2019 at 11:03):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 19 2019 at 17:28):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 19 2019 at 17:31):

@nikomatsakis thanks; the conflicts are resolved

view this post on Zulip acfoltzer (Nov 21 2019 at 17:48):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:33):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:34):

@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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:34):

Actually I don't know the status :)

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:34):

I'm quite behind

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:34):

BTW, I'll be away next week for vacation

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:35):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:35):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:35):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:35):

or maybe it's in the PRs

view this post on Zulip centril (Nov 21 2019 at 18:36):

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

view this post on Zulip centril (Nov 21 2019 at 18:36):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:36):

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

The rustc branch?

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:37):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:37):

Maybe I can even do that today

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:38):

The rustc branch?

confirm

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:38):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:38):

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

I sympathize greatly!

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:39):

(I'm actually not entirely sure)

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:40):

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?

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:42):

sorry, scarfing down a hasty lunch

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:42):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:43):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:45):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:45):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:45):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:46):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:46):

"how" to unwind?

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:48):

Maybe I need to just take a look at the branch

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:48):

yes, specifically the uwtable attribute

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:48):

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

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:48):

I could imagine trying to recruit someone to push on this

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:49):

presuming none of us have the time

view this post on Zulip nikomatsakis (Nov 21 2019 at 18:49):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:50):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:50):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 21 2019 at 18:54):

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

view this post on Zulip acfoltzer (Nov 21 2019 at 21:43):

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.

view this post on Zulip acfoltzer (Nov 21 2019 at 21:44):

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

view this post on Zulip acfoltzer (Nov 21 2019 at 21:46):

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

view this post on Zulip acfoltzer (Nov 21 2019 at 21:47):

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

view this post on Zulip acfoltzer (Dec 05 2019 at 18:32):

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

view this post on Zulip nikomatsakis (Dec 05 2019 at 18:34):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 05 2019 at 18:34):

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

view this post on Zulip gnzlbg (Dec 05 2019 at 18:44):

I'm back from travelling

view this post on Zulip nikomatsakis (Dec 05 2019 at 18:55):

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

view this post on Zulip nikomatsakis (Dec 05 2019 at 18:55):

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

view this post on Zulip nikomatsakis (Dec 05 2019 at 19:21):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:41):

Hey @WG-ffi-unwind

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:41):

So I've still not had time to do anything

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:42):

But I did have an interesting chat with @Josh Triplett

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:42):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:42):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:43):

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.

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:43):

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.

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:44):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:44):

Or of course the C+unwind design

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 18:45):

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.

view this post on Zulip acfoltzer (Dec 12 2019 at 18:45):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 18:49):

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?

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:50):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:51):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:51):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:51):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:51):

@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

view this post on Zulip nikomatsakis (Dec 12 2019 at 18:51):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 18:53):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:05):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:06):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:07):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:09):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:09):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:14):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:15):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:17):

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.

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:17):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:18):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:18):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:18):

That summaries the arguments

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:18):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:18):

Yes

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:18):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:20):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:20):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:20):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:20):

it might be

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:20):

I also still think data would be really, really great

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:20):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:20):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:20):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:21):

I think it would be better, yes

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:21):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:21):

Yes, I understood

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:21):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:21):

/me ponders

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:22):

I got stuck the lsat time because my desktop was dead

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:22):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:22):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:22):

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

yeah

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:22):

I may be underestimating of course

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:22):

but I think it's close

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:22):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:25):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:29):

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.

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:32):

I guess it depends

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:32):

I don't think data is required

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:32):

Maybe not worth blocking on

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:33):

I'm basically concerned about knee-jerk reactions

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:33):

True....

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 12 2019 at 19:34):

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

view this post on Zulip nikomatsakis (Dec 12 2019 at 19:34):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 13 2019 at 02:06):

(deleted)

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 17 2019 at 21:46):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 19 2019 at 18:35):

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?

view this post on Zulip nikomatsakis (Dec 19 2019 at 18:41):

Hey @Kyle Strand -- running slow today myself

view this post on Zulip nikomatsakis (Dec 19 2019 at 18:41):

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)

view this post on Zulip nikomatsakis (Dec 19 2019 at 18:42):

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.

view this post on Zulip nikomatsakis (Dec 19 2019 at 18:43):

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

view this post on Zulip nikomatsakis (Dec 19 2019 at 18:49):

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

view this post on Zulip tmandry (Dec 19 2019 at 19:26):

@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

view this post on Zulip nikomatsakis (Dec 19 2019 at 19:26):

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

view this post on Zulip tmandry (Dec 19 2019 at 19:27):

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

view this post on Zulip tmandry (Dec 19 2019 at 19:27):

it's not a huge pain, though

view this post on Zulip tmandry (Dec 19 2019 at 19:28):

I'll throw some notes in a doc

view this post on Zulip tmandry (Dec 20 2019 at 00:15):

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

view this post on Zulip tmandry (Dec 20 2019 at 00:15):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 02 2020 at 18:31):

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

view this post on Zulip nikomatsakis (Jan 02 2020 at 18:39):

Hi :)

view this post on Zulip nikomatsakis (Jan 02 2020 at 18:40):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 02 2020 at 18:40):

Sounds reasonable.

view this post on Zulip nikomatsakis (Jan 02 2020 at 18:40):

Do you have outstanding edits, @Kyle Strand ?

view this post on Zulip nikomatsakis (Jan 02 2020 at 18:41):

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

view this post on Zulip nikomatsakis (Jan 02 2020 at 18:41):

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

view this post on Zulip nikomatsakis (Jan 02 2020 at 18:41):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 02 2020 at 18:42):

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

view this post on Zulip nikomatsakis (Jan 02 2020 at 18:42):

in particular I was thining I might make edits

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 02 2020 at 18:42):

noon EST Monday is okay.

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 02 2020 at 18:42):

Pushing edits to my branch would be fine.

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 02 2020 at 18:43):

I've just made you a collaborator on my fork

view this post on Zulip nikomatsakis (Jan 02 2020 at 18:44):

ok

view this post on Zulip nikomatsakis (Jan 09 2020 at 18:33):

Hi @WG-ffi-unwind -- so -- I was thinking

view this post on Zulip nikomatsakis (Jan 09 2020 at 18:34):

I've been wanting to schedule a lang team design meeting to present the details of "C" vs "C unwind" etc

view this post on Zulip nikomatsakis (Jan 09 2020 at 18:34):

it seems to be surprisingly hard for us to prepare a concise summary though :) (complex ..)

view this post on Zulip nikomatsakis (Jan 09 2020 at 18:35):

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.

view this post on Zulip nikomatsakis (Jan 09 2020 at 18:35):

(also, sync time :)

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 09 2020 at 18:42):

That sounds reasonable to me.

view this post on Zulip nikomatsakis (Jan 09 2020 at 18:53):

I guess the trick is to find a time =)

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 09 2020 at 19:03):

I am pretty flexible and can generally make time when others are available.

view this post on Zulip nikomatsakis (Jan 09 2020 at 19:28):

some time next week then? I can setup a doodle I guess

view this post on Zulip nikomatsakis (Jan 09 2020 at 19:28):

or maybe you can @Kyle Strand, if you have a moment

view this post on Zulip nikomatsakis (Jan 09 2020 at 19:28):

I do thnk it's worth allocating maybe even 2h for this

view this post on Zulip nikomatsakis (Jan 09 2020 at 19:29):

I also think it should be a relatively small group perhaps -- like you and I could just do it

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 09 2020 at 19:31):

Okay. Should I exclude weekends?

view this post on Zulip nikomatsakis (Jan 09 2020 at 20:00):

yes :)

view this post on Zulip acfoltzer (Jan 09 2020 at 22:05):

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

view this post on Zulip nikomatsakis (Jan 09 2020 at 22:25):

oh, that'd be good

view this post on Zulip nikomatsakis (Jan 09 2020 at 22:26):

the hope @acfoltzer is that we will schedule a sync w/ team on monday Jan 20 at noon Boston time

view this post on Zulip nikomatsakis (Jan 09 2020 at 22:26):

@Kyle Strand (you're making doodle for next week?)

view this post on Zulip acfoltzer (Jan 09 2020 at 22:31):

ah, Jan 20 is a holiday for me but I'd be able to make it

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 10 2020 at 00:05):

Yes, making the doodle now

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 10 2020 at 00:08):

Are there any other blocks of time we can immediately veto? What's the latest people can go?

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 10 2020 at 00:09):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 10 2020 at 00:13):

And also leaving out the lang team and compiler team meeting times

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 10 2020 at 00:16):

'kay, here 'tis: https://doodle.com/poll/x4c9xquauteew7gn

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 10 2020 at 20:30):

@WG-ffi-unwind

view this post on Zulip acfoltzer (Jan 10 2020 at 21:25):

done; thanks for the ping!

view this post on Zulip nikomatsakis (Jan 10 2020 at 23:43):

whoosh, that was a very fine-grained poll :) looks like monday afternoon is maybe best...

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 12 2020 at 19:24):

@Amanieu and @gnzlbg , do you want to participate in the meeting discussed above, and if so, would 6:30 am UTC work for you?

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 12 2020 at 19:24):

If that time doesn't work, please let us know and fill out the Doodle poll

view this post on Zulip Amanieu (Jan 12 2020 at 19:28):

I've updated the doodle.

view this post on Zulip Amanieu (Jan 12 2020 at 19:29):

Monday evening is looking good

view this post on Zulip gnzlbg (Jan 12 2020 at 19:44):

I've updated the doodle as well

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 12 2020 at 20:18):

Thanks for the quick response! 6am UTC tomorrow it is.

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 12 2020 at 20:20):

I've sent an invite to Niko, but I don't seem to have the rest of you in my email contacts list.

view this post on Zulip Amanieu (Jan 12 2020 at 20:25):

amanieu@gmail.com

view this post on Zulip Amanieu (Jan 12 2020 at 20:26):

Also, the selected time on doodle is 8pm UTC. Not sure where you got 6am from?

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 13 2020 at 05:24):

I was adding instead of subtracting to get UTC from my local time. Oops.

view this post on Zulip gnzlbg (Jan 13 2020 at 17:16):

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

view this post on Zulip nikomatsakis (Jan 13 2020 at 18:36):

BTW I don't think the lang-team design meeting will happen until Feb due to MLK Jr Day here in the US

view this post on Zulip nikomatsakis (Jan 13 2020 at 18:36):

but I still think we should try to get this done

view this post on Zulip acfoltzer (Jan 16 2020 at 18:29):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:34):

I also have nothing to add since our call. I have not had time yet to translate our thoughts Monday into a blog post.

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:36):

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.

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:36):

I am aware of one layoff from within Cranelift, but there may be more

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:37):

I don't know more than you do I don't think

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:38):

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

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:38):

is that you, @Kyle Strand ?

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:38):

I think it's a good idea to produce a document that avoids too much background -- think of the lang team as audience

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:38):

The spirit is willing but the flesh is time-constrained

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:38):

I think a explainer with background is probably also good but separately :)

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:38):

lol fair

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:38):

I had a few other thoughts after our call

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:38):

one thing I was thinking of

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:39):

is that I feel like we have a large number of desiderata

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:39):

that we often failed to remember

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:39):

e.g., "can insert a shim into extern C fn" or something

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:39):

maybe a table would make sense

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:39):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:40):

Function pointers seem like an oft-neglected consideration

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:40):

Despite the fact that we're all aware of the complications therein, having previously discussed them!

view this post on Zulip acfoltzer (Jan 16 2020 at 18:41):

I can help with an editing pass and other feedback but unfortunately my time is extremely constrained

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:41):

Re: explainer:

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:41):

I'm not 100% sure what that refers to :)

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:41):

background material?

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:41):

if so, maybe push to the repo and then write a blog post announcing it exists

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:42):

I think people would be interested

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:43):

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

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:43):

yeah that's what I figured you meant

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:43):

seems great

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:44):

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.

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:45):

+1

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:45):

I might try my hand at making this table I was talking about

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:45):

oh and

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:46):

I plan to schedule a lang team meeting sometime in Feb -- it'll be a design meeting, so monday at noon Eastern time

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:46):

do y'all have any preferences when it comes to weeks?

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:46):

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

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:46):

I can make a doodle if needed :)

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:47):

Looks like I have no prior commitments on any Monday in February.

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:49):

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

view this post on Zulip acfoltzer (Jan 16 2020 at 18:49):

the week of the 10th I'm in the bay area for a bunch of wasm meetings

view this post on Zulip acfoltzer (Jan 16 2020 at 18:50):

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

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:51):

I don't feel you have to attend

view this post on Zulip acfoltzer (Jan 16 2020 at 18:51):

which is to say, other than the 10th all of my Mondays are pretty much free

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:51):

I guess @Amanieu your schedule would be pretty relevant too

view this post on Zulip Amanieu (Jan 16 2020 at 18:51):

I'm away on a ski trip for the 1st week of Feb

view this post on Zulip acfoltzer (Jan 16 2020 at 18:51):

I would like to, because having a concrete commitment helps me actually prioritize paying attention to this issue despite our product managers :pray:

view this post on Zulip Amanieu (Jan 16 2020 at 18:52):

But after that it should be fine

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:57):

I am reminded that I will be on vacation Feb 17

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:58):

So that means:

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:58):

heh

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:58):

seems far away

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:58):

but then...

view this post on Zulip Amanieu (Jan 16 2020 at 18:58):

Unless we can fit it in late Jan?

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:58):

I'm not avail next 2 weeks

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:59):

I guess maybe next week

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:59):

it's a holiday :)

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:59):

but ..

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:59):

my partner would kill me :P

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:59):

could shoot for another day of the week, it's just that it's hard to find those

view this post on Zulip Amanieu (Jan 16 2020 at 18:59):

Let's not then. A dead niko is an unproductive niko.

view this post on Zulip nikomatsakis (Jan 16 2020 at 18:59):

scheduling is hard :)

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 18:59):

@acfoltzer any chance of trying to schedule this between your wasm meetings?

view this post on Zulip nikomatsakis (Jan 16 2020 at 19:00):

let's do this: try to write it up asap,

view this post on Zulip nikomatsakis (Jan 16 2020 at 19:00):

plan to talk feb 24, but see if we can find an earlier time, and/or conduct the discussion async

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 19:00):

Conduct the discussion w/ the lang team async?

view this post on Zulip nikomatsakis (Jan 16 2020 at 19:00):

yeah, maybe hopeless tho

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 19:00):

(I thought that was what we were scheduling for Feb)

view this post on Zulip nikomatsakis (Jan 16 2020 at 19:00):

it is:)

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 19:00):

mm

view this post on Zulip nikomatsakis (Jan 16 2020 at 19:01):

I'm mostly thiking that the solution to "Scheduling hell" is async, but it only sometimes works

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 19:01):

Well, to be fair, I wasn't really hoping for _consensus_ among the team from one meeting, necessarily.

view this post on Zulip nikomatsakis (Jan 16 2020 at 19:01):

I definitely think it'd be better if we can start the conversation earlier

view this post on Zulip nikomatsakis (Jan 16 2020 at 19:01):

regardless

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 19:01):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 19:01):

team_meeting.await

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 16 2020 at 19:04):

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

view this post on Zulip acfoltzer (Jan 16 2020 at 19:05):

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

view this post on Zulip acfoltzer (Jan 16 2020 at 19:05):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 23 2020 at 17:41):

@WG-ffi-unwind Sorry all, I didn't actually make any headway on anything this week.

view this post on Zulip acfoltzer (Jan 23 2020 at 18:31):

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

view this post on Zulip acfoltzer (Jan 23 2020 at 18:31):

and, of course, the opportunity for high-bandwidth collaboration with anyone else on the team who will be there :slight_smile:

view this post on Zulip nikomatsakis (Jan 23 2020 at 18:39):

:wave: been busy, I didn't get too far either :)

view this post on Zulip nikomatsakis (Jan 23 2020 at 18:39):

sorry, had a call come up this week, too

view this post on Zulip nikomatsakis (Jan 23 2020 at 18:39):

meant to ping earlier but ..

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 23 2020 at 18:41):

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.

view this post on Zulip acfoltzer (Jan 23 2020 at 18:42):

oh wow, that's so exciting!

view this post on Zulip acfoltzer (Jan 23 2020 at 18:42):

looking forward to meeting you :)

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 23 2020 at 18:51):

Same!

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 29 2020 at 18:34):

I will be interviewing tomorrow, so I will not be able to join our weekly chat.

view this post on Zulip acfoltzer (Jan 29 2020 at 23:50):

good luck!

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 29 2020 at 23:50):

Thanks!

view this post on Zulip acfoltzer (Feb 06 2020 at 18:33):

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:

view this post on Zulip acfoltzer (Feb 06 2020 at 18:34):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 06 2020 at 18:38):

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. :/

view this post on Zulip acfoltzer (Feb 06 2020 at 18:39):

... and someone just drove into our parked car out front. gotta run I guess

view this post on Zulip acfoltzer (Feb 06 2020 at 18:54):

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

view this post on Zulip nikomatsakis (Feb 06 2020 at 22:21):

I've not had time to do anything

view this post on Zulip nikomatsakis (Feb 06 2020 at 22:22):

I still hope to put in some time to creating a doc or collating our results from before

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 13 2020 at 18:36):

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

view this post on Zulip acfoltzer (Feb 13 2020 at 18:39):

it seems like our activity has been slow enough that fortnightly should be fine. we can always adjust when things pick up?

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 13 2020 at 18:39):

I agree.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 13 2020 at 18:40):

In any case, there won't be a conflict next week, which is our last scheduled meeting time before the lang team discussion.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 13 2020 at 18:41):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 13 2020 at 18:42):

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.

view this post on Zulip nikomatsakis (Feb 14 2020 at 16:39):

Thanks for bringing that up, I meant to

view this post on Zulip nikomatsakis (Feb 14 2020 at 16:40):

@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

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 17 2020 at 22:30):

@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

view this post on Zulip Amanieu (Feb 18 2020 at 13:51):

I can do a second round of review on the blog post after you make your changes if you want.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 19 2020 at 00:51):

Sorry, I thought I'd have time to make changes yesterday but didn't.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 19 2020 at 03:06):

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

view this post on Zulip nikomatsakis (Feb 19 2020 at 11:06):

I'm taking a look at the blog post now

view this post on Zulip nikomatsakis (Feb 19 2020 at 11:29):

@Kyle Strand you're not around now, by any chance?

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 19 2020 at 15:01):

I hope you are traveling rather than working at some terrible hour of the night!

view this post on Zulip nikomatsakis (Feb 20 2020 at 14:08):

@Kyle Strand I am working very early hours =)

view this post on Zulip nikomatsakis (Feb 20 2020 at 14:08):

as I'm traveling

view this post on Zulip nikomatsakis (Feb 20 2020 at 14:32):

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

view this post on Zulip nikomatsakis (Feb 20 2020 at 14:32):

that said, I had some edits that felt productive

view this post on Zulip nikomatsakis (Feb 20 2020 at 14:32):

I just got called off on other things

view this post on Zulip nikomatsakis (Feb 20 2020 at 14:32):

maybe I'll push a branch to my repo

view this post on Zulip Amanieu (Feb 20 2020 at 14:52):

@Kyle Strand If you're too busy, I can take over finishing up the blog post.

view this post on Zulip acfoltzer (Feb 20 2020 at 18:31):

hey folks, just saw https://github.com/rust-lang/project-ffi-unwind/pull/21 and am taking a look now

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 18:34):

@Amanieu Well, currently it seems like the most important "work item" is to resolve the points of confusion brought up in the review.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 18:34):

I'm not sure that's a "who has time" thing, exactly

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 18:35):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 18:37):

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?

view this post on Zulip Amanieu (Feb 20 2020 at 18:38):

It should be sound.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 18:38):

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

view this post on Zulip Amanieu (Feb 20 2020 at 18:39):

I think that may have just been an implementation issue rather than a fundamental one.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:15):

Okay, I'm making some changes in accordance with that.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:16):

Re: this discussion: https://github.com/rust-lang/project-ffi-unwind/pull/21#discussion_r381232338

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:16):

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?

view this post on Zulip Amanieu (Feb 20 2020 at 19:18):

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.

view this post on Zulip Amanieu (Feb 20 2020 at 19:18):

The idea with extern "C unwind" is that you opt-in to those shims on -C panic=abort.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:22):

Agreed, but that discussion is about -Cpanic=unwind.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:23):

Niko was asking if a panic-unwind reaching an extern "C" boundary under panic=unwind should be UB.

view this post on Zulip acfoltzer (Feb 20 2020 at 19:24):

perhaps we could insert a shim there in debug mode only?

view this post on Zulip Amanieu (Feb 20 2020 at 19:24):

Oh right. Yes, we do insert a shim there.

view this post on Zulip Amanieu (Feb 20 2020 at 19:25):

Hmm, the problem is that we want to allow forced exceptions. So the shim would have to differentiate between them.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:26):

Only in proposal 2!

view this post on Zulip Amanieu (Feb 20 2020 at 19:26):

No, we want to always allow longjmp over extern "C" frames.

view this post on Zulip Amanieu (Feb 20 2020 at 19:26):

er

view this post on Zulip Amanieu (Feb 20 2020 at 19:27):

At least I think we do, for backward compatibility reasons.

view this post on Zulip Amanieu (Feb 20 2020 at 19:27):

(rlua)

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:27):

.... reconsidering, you're correct

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:27):

Sorry

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:28):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:28):

Correct?

view this post on Zulip Amanieu (Feb 20 2020 at 19:32):

Hmm

view this post on Zulip Amanieu (Feb 20 2020 at 19:33):

view this post on Zulip Amanieu (Feb 20 2020 at 19:34):

(i need to go re-read the doc, got a link?)

view this post on Zulip Amanieu (Feb 20 2020 at 19:38):

### 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

view this post on Zulip Amanieu (Feb 20 2020 at 19:38):

Only proposal 2 treats forced unwinding and other foreign unwinding differently

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:42):

The Paper doc?

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 19:42):

https://paper.dropbox.com/doc/ffi-unwind-2020-01-13-agituL322N0qRsCbcnn7D

view this post on Zulip Amanieu (Feb 20 2020 at 19:49):

See my comment about for proposal 1.

view this post on Zulip Amanieu (Feb 20 2020 at 19:51):

For proposal 2, same as 1 but "C unwind" allows forced exceptions in -Cpanic=abort

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 20:12):

Okay, I've fixed it up and transposed the table.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 20:12):

Would you mind looking at the table again?

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 20:12):

I can merge the PR so you can make additional changes in a new PR if youd' like

view this post on Zulip Amanieu (Feb 20 2020 at 20:16):

@Kyle Strand row 1 column 3 should be "unwind" instead of "abort".

view this post on Zulip Amanieu (Feb 20 2020 at 20:17):

But sure, go ahead and merge. I'll send a PR with extra changes on top of yours.

view this post on Zulip Amanieu (Feb 20 2020 at 20:17):

In particular I want to add a list of pros/cons for each proposal.

view this post on Zulip Amanieu (Feb 20 2020 at 20:18):

last row column 3 should also be "unwind"

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 20:49):

Okay, I've fixed those, made a few more small fixes based on other PR comments, and merged!

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 20 2020 at 20:50):

Thanks for taking on the additional work

view this post on Zulip Amanieu (Feb 21 2020 at 10:06):

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.

view this post on Zulip Amanieu (Feb 21 2020 at 10:07):

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

view this post on Zulip Amanieu (Feb 21 2020 at 10:08):

Or if you have a Rust function that panics that is called from C++, and want panics to propagate through the C++.

view this post on Zulip Amanieu (Feb 21 2020 at 10:08):

Either way, you don't really care about forced unwinds for those cases...

view this post on Zulip Amanieu (Feb 21 2020 at 10:09):

If you have any ideas, let me know what you think the main advantages of proposal 2 are over 1&3.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 21 2020 at 15:25):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 21 2020 at 15:25):

But I think overall that's a good observation.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 21 2020 at 15:39):

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?

view this post on Zulip Amanieu (Feb 21 2020 at 16:08):

There shouldn't be an issue. In C++ noexcept will also cause forced unwinding to abort.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 21 2020 at 16:13):

Oh, that makes sense.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 21 2020 at 23:20):

@Amanieu Thanks again for adding to the blog post draft. I'd suggest adding your name to the byline along with me and Niko

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 21 2020 at 23:21):

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?

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 21 2020 at 23:21):

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

view this post on Zulip Amanieu (Feb 21 2020 at 23:22):

Yea sorry about that I had a busy day and got to reviewing the blog post quite late.

view this post on Zulip Amanieu (Feb 21 2020 at 23:26):

I pushed some more fixes. If it looks good you should just merge it and push out the blog post tonight.

view this post on Zulip Amanieu (Feb 21 2020 at 23:27):

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.

view this post on Zulip Amanieu (Feb 21 2020 at 23:28):

I'm going to sleep now, so if you want to make more changes just merge mine first.

view this post on Zulip nikomatsakis (Feb 22 2020 at 10:47):

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.

view this post on Zulip nikomatsakis (Feb 22 2020 at 10:47):

I probably wont' get one until Monday

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 22 2020 at 16:59):

@Amanieu no apology necessary - most of the delay was just because I didn't have time to do much these last few weeks.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 22 2020 at 17:01):

@nikomatsakis let's push the meeting back; perhaps another Doodle would be good?

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 22 2020 at 17:31):

I think the blog post is ready to publish once we put a new date in there.

view this post on Zulip Amanieu (Feb 22 2020 at 17:44):

Do we want to have a small discussion on whether to eliminate proposal 2 before publishing the blog post? Or just leave it in?

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 22 2020 at 17:49):

Hm... I think I'd prefer to leave it, at least until the lang team has a preliminary opportunity to take a look.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 22 2020 at 17:51):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 22 2020 at 17:53):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 22 2020 at 17:54):

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"

view this post on Zulip Amanieu (Feb 22 2020 at 17:56):

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.

view this post on Zulip Amanieu (Feb 22 2020 at 17:56):

I g2g now, but I can write something up later.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 22 2020 at 18:25):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 23 2020 at 21:07):

@Amanieu https://github.com/rust-lang/project-ffi-unwind/pull/24

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 27 2020 at 18:50):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 27 2020 at 18:52):

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?

view this post on Zulip acfoltzer (Feb 27 2020 at 20:48):

sorry, I thought we were moving to fortnightly

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 27 2020 at 21:04):

@acfoltzer Oh, you may be right.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 27 2020 at 21:22):

In fact checking back over our chat logs, that was indeed the decision. I'll adjust the meeting invite

view this post on Zulip acfoltzer (Feb 27 2020 at 21:22):

thanks! sorry that you showed up to an empty room though :(

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 27 2020 at 21:23):

Amanieu was around, so it wasn't _too_ lonely!

view this post on Zulip acfoltzer (Mar 05 2020 at 18:25):

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:

view this post on Zulip acfoltzer (Mar 05 2020 at 18:26):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 05 2020 at 18:35):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 05 2020 at 18:36):

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.

view this post on Zulip nikomatsakis (Mar 05 2020 at 18:37):

hey all

view this post on Zulip Amanieu (Mar 05 2020 at 18:59):

@BatmanAoD (Kyle Strand) Sure, add me to the group.

view this post on Zulip acfoltzer (Mar 19 2020 at 17:30):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:32):

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

view this post on Zulip Amanieu (Mar 19 2020 at 17:33):

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.

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:34):

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.

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:34):

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!

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:34):

I'm curious also how you think that should interact with forced exceptions

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:35):

As long as the exception is rethrown, my understanding is that catching forced exceptions should work just like catching unforced exceptions.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:35):

(By "my understanding" I mean "I think this is what LLVM/C++/etc expect".)

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:36):

I guess I don't know what catch_unwind "catching and rethrowing" foreign exceptions really means

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:36):

like, I don't know what interface is being expsed to Rust users

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:36):

I'm thinking about how C++ lets you catch "any exception", but doing so w/o rethrowing seems to be a kind of bug

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:37):

(because you can intercept forced exceptions and fail to rethrow)

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:40):

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

view this post on Zulip Amanieu (Mar 19 2020 at 17:42):

Basically catch_unwind returns a Box<ForeignException> and resume_unwind magically turns that back into the original exception.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 19 2020 at 17:42):

Reviewing some older threads: one need, it seems, is the ability to re-throw the foreign exception from a different thread. Correct?

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:45):

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"

view this post on Zulip Amanieu (Mar 19 2020 at 17:45):

Yes, sending the exception to another thread will work fine.

view this post on Zulip Amanieu (Mar 19 2020 at 17:47):

There is no special handling for forced exceptions at the moment, but I can easily change catch_unwind to ignore foreign exceptions if necessary.

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:47):

I'm not sure if it should ignore them, seems maybe bad

view this post on Zulip nikomatsakis (Mar 19 2020 at 17:48):

(But anyway that's something that can be hammered out at some point)

view this post on Zulip nikomatsakis (Mar 26 2020 at 18:56):

@acfoltzer were you ever able to write up a comment?

view this post on Zulip acfoltzer (Apr 02 2020 at 17:21):

nikomatsakis said:

acfoltzer were you ever able to write up a comment?

gah, Zulip signed me out in the background, I missed this :disappointed:

view this post on Zulip acfoltzer (Apr 02 2020 at 17:21):

that's what I get for turning off all the email notifications I can

view this post on Zulip acfoltzer (Apr 02 2020 at 17:43):

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:

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:49):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:49):

I.e., I would generally expect that one of Rust's values is "do the right thing by default".

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:50):

And that another is "UB is usually not 'the right thing'".

view this post on Zulip centril (Apr 02 2020 at 17:52):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:54):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 02 2020 at 17:54):

@centril That's why Adam is saying that introducing a new ABI is problematic.

view this post on Zulip centril (Apr 02 2020 at 17:55):

@acfoltzer by subtyping do you include coercions?

view this post on Zulip centril (Apr 02 2020 at 17:56):

I ask because there's regular confusion between the two concepts

view this post on Zulip centril (Apr 02 2020 at 17:56):

Many don't actually mean subtyping when they use the term

view this post on Zulip centril (Apr 02 2020 at 18:00):

@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

view this post on Zulip centril (Apr 02 2020 at 18:01):

&'lifetime extern "C" fn() would also be an example, but that seems like an unusual type

view this post on Zulip acfoltzer (Apr 02 2020 at 18:02):

coercions would suffice as well, but it'd still be complicated to work out which coercions are valid where, because functions are contravariant

view this post on Zulip acfoltzer (Apr 02 2020 at 18:03):

I say subtyping because that's how I think about it from my academic PL background :)

view this post on Zulip centril (Apr 02 2020 at 18:04):

@acfoltzer that's surprising, precisely because from a type theoretic perspective (at least that which I know of) coercions are understood as something else

view this post on Zulip acfoltzer (Apr 02 2020 at 18:05):

for this topic I'm leaning on my knowledge of the multi-language semantics literature, contracts, blame calculus, etc

view this post on Zulip centril (Apr 02 2020 at 18:06):

To my knowledge we have generic infrastructure for handling contravariance and such

view this post on Zulip acfoltzer (Apr 02 2020 at 18:06):

I'm less of a type theorist :)

view this post on Zulip centril (Apr 02 2020 at 18:06):

(with respect to coercions)

view this post on Zulip acfoltzer (Apr 02 2020 at 18:08):

I should probably re-read https://doc.rust-lang.org/nomicon/coercions.html

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 02 2020 at 18:12):

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 ?

view this post on Zulip centril (Apr 02 2020 at 18:13):

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

view this post on Zulip acfoltzer (Apr 02 2020 at 18:15):

got it, that makes sense

view this post on Zulip centril (Apr 02 2020 at 18:22):

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

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:15):

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.

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:15):

but I don't know that we have to post them in t-lang necessarily

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:16):

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:

view this post on Zulip Josh Triplett (Apr 03 2020 at 19:17):

Would unifying them lead to a substantial degree of additional code size by default?

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:20):

If we unified them, it would mean that:

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:20):

However, the downside is that you may have some library that interacts with c++ code where that C++ code throws an exception

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:20):

This Rust library is UB to use with panic=abort

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:21):

But you won't really get any kind of "warning" about that, we don't really have a way to "signal that" now

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:21):

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

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:21):

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.

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:22):

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.

view this post on Zulip nikomatsakis (Apr 03 2020 at 19:23):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 03 2020 at 20:00):

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)

view this post on Zulip nikomatsakis (Apr 06 2020 at 21:52):

Yes, correct, sorry.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:30):

@WG-ffi-unwind Weekly check-in!

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:30):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:30):

Nothing else to report at this time.

view this post on Zulip Amanieu (Apr 16 2020 at 17:31):

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.

view this post on Zulip acfoltzer (Apr 16 2020 at 17:31):

I have the RFC draft on my github review queue, but that queue is currently growing faster than I can get through :upside_down:

view this post on Zulip acfoltzer (Apr 16 2020 at 17:32):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:32):

Okay, understandable.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:33):

Are you okay with moving forward under the assumption that we'll introduce "C unwind"?

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:33):

That's the main thing we might need your input on

view this post on Zulip acfoltzer (Apr 16 2020 at 17:33):

I feel very comfortable that my perspective has been incorporated so far, and yes, okay with "C unwind"

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:33):

:+1:

view this post on Zulip acfoltzer (Apr 16 2020 at 17:33):

I still have a preference for "C" but not a deeply held one

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:33):

I think I'm in a similar boat

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:34):

Fortunately, I think most of the RFC text will be similar regardless of which we pick

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:34):

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)

view this post on Zulip acfoltzer (Apr 16 2020 at 17:35):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:36):

I think it's probably the case that both solutions will meet everyone's _needs_ but not necessarily everyone's "ideal case"

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:36):

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!

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:37):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 17:39):

Well, unless @nikomatsakis has anything to add, I think we can call that a wrap

view this post on Zulip nikomatsakis (Apr 16 2020 at 18:39):

Sorry, I was distracted today

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 16 2020 at 18:55):

No problem.

view this post on Zulip acfoltzer (Apr 30 2020 at 17:21):

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

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:22):

I'm around was going to go take a fresh look

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:23):

I do have a bit of a "ok let's just do this thing" feeling

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:24):

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

view this post on Zulip acfoltzer (Apr 30 2020 at 17:25):

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

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:25):

I would like it that people who read it .. yeah .. understand well what it means

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:26):

but also some of that enery can go into writing up docs for the reference

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:34):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:34):

The 'unwinding' framing matches the name of the new ABI string pretty well, which I think is a plus.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:36):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:37):

@WG-ffi-unwind I think everyone interested in the weekly sync-up may already be here, but just in case, here's your notification!

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:41):

I'm checking out your PR locally

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:42):

I was curious to read it again and experiment a bit

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:42):

I'm not sure I follow the idea that it will require massive rewrites

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:46):

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.

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:47):

re-reading it, I think it seems "pretty ok",

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:48):

although I find the phrase "unforced foreign unwind" (sometimes we say "non-forced foreign unwind"...) kind of confusing

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:48):

"nonunforced"?

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:48):

Please tell me I didn't write that :laughing:

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:48):

no, you wrote unforced and non-forced

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:48):

ah

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:48):

both of which are confounding to me :)

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:49):

i.e., I know what it means

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:49):

"unforced error"

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:49):

but my brain has to sit and decode it

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:49):

like in Tennis

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:49):

I would rather just say "foreign unwind"

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:49):

this is a flaw in the terminology, I guess, which suggested that foreign unwind is the superset of the two

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:49):

when that is just not a useful concept, since they share nothing in common in terms of our behavior

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:49):

it'd be better to just call it "forced unwind" in this way :)

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:49):

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"

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:49):

I'd be in favor of that

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:50):

I think we should call it

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:50):

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"

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:51):

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"

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:51):

Not to toot my own horn, but taking the forced-unwind columns out of the table entirely was a good decision, I think.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:52):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 17:53):

Wherever else forced unwinding shows up, I'll make sure it's more of a footnote - "see the force unwind disclaimer"

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:57):

I'm currently editing the motivation a bit

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:57):

do you mind if I push some commits to your branch?

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:57):

I'll ping you when I do

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:58):

I'm trying to address my point about adding in our design constriants

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:58):

@BatmanAoD (Kyle Strand) :point_up:

view this post on Zulip nikomatsakis (Apr 30 2020 at 17:59):

I think one remaining interesting point is what to say about foreign exceptions propagating through Rust frames

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:01):

I do not mind

view this post on Zulip nikomatsakis (Apr 30 2020 at 18:07):

@BatmanAoD (Kyle Strand) take a look!

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:11):

Looks good, though shouldn't the 'analysis of key design goals' subsection go in the 'rationale' section?

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:12):

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?

view this post on Zulip nikomatsakis (Apr 30 2020 at 18:13):

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

view this post on Zulip nikomatsakis (Apr 30 2020 at 18:13):

one thing though

view this post on Zulip nikomatsakis (Apr 30 2020 at 18:13):

I think we should a "key goal" to be enabling longjmp-based error handling

view this post on Zulip nikomatsakis (Apr 30 2020 at 18:14):

I forgot that I think

view this post on Zulip nikomatsakis (Apr 30 2020 at 18:14):

I think that kind of covers the "three scenarios" we care about?

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:22):

Well, I noticed that I already had a very similar bullet-point list, based on the Inside Rust post's list.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:23):

One that was missing from your list, which I've now incorporated, is keeping the libc API stable.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:23):

That's sort of the same requirement, is it? Though it should be rephrased to explain why it's relevant.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:23):

Hmmmm never mind, sorry, that's b/c of pthread_exit, not longjmp

view this post on Zulip nikomatsakis (Apr 30 2020 at 18:26):

regardless it's ok to say twice :)

view this post on Zulip nikomatsakis (Apr 30 2020 at 18:26):

but I do feel it's distinct

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:26):

Oh, I was thinking that if they were the same issue, it could be rephrased to focus on longjmp instead of libc

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:26):

but they are not the same, so I'll introduce a new bullet.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:40):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 30 2020 at 18:40):

I think I suggested "disposable"?

view this post on Zulip nikomatsakis (May 01 2020 at 20:49):

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)

view this post on Zulip nikomatsakis (May 01 2020 at 20:49):

I refrained from suggesting it, but it felt like a "concept" that arose a few times

view this post on Zulip nikomatsakis (May 01 2020 at 20:49):

and sometimes we were consistent with saying "or catch-unwind"

view this post on Zulip nikomatsakis (May 01 2020 at 20:49):

and sometimes we just talked about destructors

view this post on Zulip nikomatsakis (May 01 2020 at 20:49):

an option might be to .. steal a term like POD?

view this post on Zulip nikomatsakis (May 01 2020 at 20:49):

that's probably confusing

view this post on Zulip BatmanAoD (Kyle Strand) (May 01 2020 at 21:21):

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.

view this post on Zulip nikomatsakis (May 01 2020 at 21:51):

I think we can wave our hands and say "destructors in scope"

view this post on Zulip nikomatsakis (May 01 2020 at 21:51):

it's good enough for now

view this post on Zulip nikomatsakis (May 01 2020 at 21:52):

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)

view this post on Zulip simulacrum (May 01 2020 at 22:39):

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

view this post on Zulip BatmanAoD (Kyle Strand) (May 01 2020 at 22:59):

Do either of you know why it's called "glue"?

view this post on Zulip simulacrum (May 02 2020 at 00:34):

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

view this post on Zulip nikomatsakis (May 02 2020 at 10:25):

simulacrum said:

it's a bit unfortunate we don't have a nice term here though I think

I know

view this post on Zulip nikomatsakis (May 02 2020 at 10:26):

the term glue code predates me, but it was used for any automatically generated code that walked the type structure

view this post on Zulip simulacrum (May 02 2020 at 11:48):

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.

view this post on Zulip simulacrum (May 02 2020 at 11:49):

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)

view this post on Zulip Amanieu (May 02 2020 at 12:31):

Also because of drop flags we may still have landing pads while not have any destructors to execute.

view this post on Zulip Amanieu (May 02 2020 at 12:31):

let x;
if (foo)
    x = String::new("foo");
longjmp();

view this post on Zulip Amanieu (May 02 2020 at 12:33):

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.

view this post on Zulip nikomatsakis (May 04 2020 at 14:10):

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

view this post on Zulip BatmanAoD (Kyle Strand) (May 04 2020 at 14:38):

Really? I would not expect LLVM to make that UB...

view this post on Zulip Amanieu (May 04 2020 at 16:52):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 17:34):

@WG-ffi-unwind Biweekly check-in!

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 17:35):

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.

view this post on Zulip acfoltzer (May 14 2020 at 17:35):

: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

view this post on Zulip nikomatsakis (May 14 2020 at 17:38):

No real updates, I'd like to post the RFC

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 17:31):

@WG-ffi-unwind Biweekly check-in. No updates from me, I'm afraid, but I might be able to finish up the RFC and get it ready for submission to rust-lang/rfcs within the next few days.

view this post on Zulip nikomatsakis (May 28 2020 at 17:31):

no update on my part except that this would be excellent!

view this post on Zulip nikomatsakis (May 28 2020 at 17:31):

I don't really mind the delay, @BatmanAoD (Kyle Strand), but if finishing up the RFC is stressing you in particular let me know and maybe I can take it off your hands

view this post on Zulip nikomatsakis (May 28 2020 at 17:31):

or maybe @acfoltzer can :P

view this post on Zulip nikomatsakis (May 28 2020 at 17:32):

/me volunteers other people

view this post on Zulip acfoltzer (May 28 2020 at 17:32):

aaaaaaa

view this post on Zulip nikomatsakis (May 28 2020 at 17:32):

:P

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 17:32):

It's just a lack of time :shrug:

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 17:32):

And energy, I guess. But no, the specific task is no big deal.

view this post on Zulip acfoltzer (May 28 2020 at 17:33):

I am willing to help but this week is pretty bad. I have more light in my calendar next week though

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 17:33):

Oh, and it sounds like we're aligned enough on the "POF" terminology to move forward with that. Which removes the only blocker.

view this post on Zulip acfoltzer (May 28 2020 at 17:34):

(we're currently onboarding Aaron Turon as our team's new manager, which is a rare experience to be savored)

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 17:35):

That's awesome!

view this post on Zulip acfoltzer (May 28 2020 at 17:35):

actually, that's more than a parenthetical. I'm hoping that once Aaron is more up to speed, that he can help drive things forward in this group as well. he has a little bit more experience than I do at getting RFCs though :)

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 17:38):

Well, is that a wrap for today?

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 17:46):

Sounds like it. Stay safe and sane, everyone!

view this post on Zulip nikomatsakis (May 28 2020 at 17:54):

acfoltzer said:

(we're currently onboarding Aaron Turon as our team's new manager, which is a rare experience to be savored)

lol I was considering making some kind of joke about "I know your manager and can get you assigned to this" but I couldn't figure out how to make it funny

view this post on Zulip acfoltzer (Jun 11 2020 at 17:25):

Hey folks, early check-in for me since I have a conflict for our usual time. @Aaron Turon has agreed to help represent the Fastly use case here while I am buried in (sadly unrelated, but fun) product work. From our perspective, we are fine with not handling longjmps at first. It really is the panics that we want to be able to propagate

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:27):

I'm a bit concerned about doing anything that would break longjmp, though, because currently it is "soft-guaranteed" to work.

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:27):

I.e. it's not in the Reference, but there have been numerous assurances that longjmp works as expected

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:31):

@WG-ffi-unwind Bi-weekly check-in!

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:31):

:wave:

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:31):

it's been an interesting week :)

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:32):

So, there are basically two outstanding points of potential concern, right?

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:32):

Or maybe three

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:32):

The RFC draft may be good enough at this point to merge; but we have some items to look into before we open an rfcs repo PR

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:32):

^ yes

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:33):

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:33):

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:34):

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:34):

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:34):

(jinx)

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:35):

and I guess the follow-up is, if we do, what are we doing to do about it ;)

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:35):

I personally care a little :)

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:35):

but I'm not sure yet what I think would be a solution

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:36):

Q: is this also a problem for pthread exit?

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:36):

Seems like it would be...

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:36):

but I feel like it would be reasonable to move forward with the RFC but leaving longjmp and "forced exceptions" as an unresolved question -- I guess the tl;dr is that we could in principle require some extra annotation to indicate when you are calling a function that may not return

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:37):

which btw ties in with the UB question

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:37):

i.e., violating such an annotation would presumably be UB

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:37):

(and without it, all functions would be assumed to either terminate or return in some "controlled fashion" (unwinding or ordinary return))

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:37):

BatmanAoD (Kyle Strand) said:

Q: is this also a problem for pthread exit?

yes

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:38):

all the same arguments against annotations apply of course

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:38):

i.e., you could argue it should be an ABI

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:38):

though it feels awfully niche to me

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:38):

still, you could imagine wanting to call a function by pointer etc etc

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:39):

nikomatsakis said:

all the same arguments against annotations apply of course

I feel like I want to think this through, actually

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:39):

of the two, longjmp is probably a lot less niche than pthread_exit

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:39):

right, but you mentioned libc yesterday, which IIRC is only a problem b/c of pthread_exit, not longjmp

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:39):

correct

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:40):

nikomatsakis said:

(and without it, all functions would be assumed to either terminate or return in some "controlled fashion" (unwinding or ordinary return))

abort should also be legal, correct? B/c even though it doesn't do cleanup, it shouldn't need to

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:40):

(though, thinking more on it, I have to wonder if having some variant of read (read_exit or something) that is declared with a distinct UB (but links to the same C function) might be reasonable)

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:40):

yes, terminate = abort

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:40):

I don't know how we say that "more formally" somehow

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:41):

well I guess just like that basically

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:41):

so long as the process continues to exist...

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:41):

anyway, leaving aside the "formalities" of it...

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:41):

we hvae plenty of mechanisms that abort, so obviously that has to be ok

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:41):

Basically, destructors are only as "guaranteed" as they ever have been in any language :laughing:

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:42):

right =) it's most interesting for &mut in shared memory

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:42):

(I think the answer there is that this concept is incorrect)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:42):

sorry, which concept?

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:42):

giving an &mut to shared memory

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:43):

I have to kind of pin down the right way to express it, but there's some bit of the &mut exclusiveness guarantee that you can't uphold

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:43):

(tied in with this notion of ending a process)

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:43):

anyway I do feel like this can be left unresolved, though I'm not sure just what that implies for the RFC

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:44):

and we will want to go on and resolve it :(

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:44):

I don't actually think the argument for function-pointer annotations applies here, actually. An annotation indicating "this function might not return normally" doesn't affect the _call site_, does it?

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:44):

it does

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:45):

as the compiler can't optimize around it in the same way

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:47):

well, a call to a function that might not return normally due to longjmp must only occur in another such function, unless it's the function with the corresponding setjmp

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:48):

so my impulse is to say "it's UB to longjmp over frames that aren't annotated as may-not-return"

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:48):

(for pthread_exit, the entire thread must be comprised of such frames)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:49):

So the optimizations can only occur in the functions that are annotated that way.

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:49):

/me thinks

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:49):

ok, so, that's true

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:49):

so you're basically saying that if we tagged #[longjmp] (or whatever) on each fn that might be unwound

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:49):

this also fits with the compiler doing checking

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:50):

BatmanAoD (Kyle Strand) said:

So the optimizations can only occur in the functions that are annotated that way.

Er, strike that, reverse it

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:50):

yes, I think so

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:50):

it's not as precise, which is why I didn't like it at first, but

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:50):

it's also probably just fine in practice

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:50):

and it is the programmer's responsibility to ensure that use of function pointers doesn't somehow let a non-longjmpable frame get put on the stack...

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:50):

i.e., the compiler would basically give you a warning if any function call occurs that has a dtor in scope

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:50):

that seems ok

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:50):

and it would have to avoid optimizing because it doesn't know if that fn may longjmp

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:51):

I forget how setjmp works

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:51):

^ ah, but not being able to give that warning is why the function pointer question is hairy

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:51):

you can give the warning

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:51):

it's just a warning

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:51):

or maybe I misunderstood you

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:51):

there are a few sources of imprecision -- one of them is that you call a fn that will never longjmp

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:51):

i.e., some helpers or something

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:52):

that seems ok to me, you get a false warning, but you can allow it

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:52):

but I still have a bit of trouble understanding how the setjmp part is meant to work -- although in most use cases, the setjmp is in C code anyway

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:53):

it seems like this frame is a bit special, it's the only one that can call a #[longjmp] function without itself getting a warning

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:53):

I think the setjmp itself has to be in C, b/c setjmp/longjmp are part of the C std lib

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:53):

and they are platform-defined

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:53):

that is, sorry, I left that implicit, but it's presumably also a lint to call a #[longjmp] fn unless your fn is #[longjmp] -- this one is also not a guarantee, because of calls by pointer, which is your point I suppose?

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:53):

ok, that's a convenient answer :)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:54):

Which warning were you describing above? Calling a non-#[longjmp] function from a #[longjmp]?

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:54):

I think that's actually always okay!

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:54):

nikomatsakis said:

it seems like this frame is a bit special, it's the only one that can call a #[longjmp] function without itself getting a warning

wait -- so -- this doesn't work great for pthread-exit, unless we do the thing I mentioned of having two read calls (one that is compatible with pthread-exit)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:54):

It's the reverse that's problematic

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:54):

I think there are two warnings

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:55):

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:55):

neither is precise, the best we can do are lints

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:55):

but I suspect in practice we catch everything

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:56):

btw let's call the annotation #[POF] for now since we've finally got some terminology for this!

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:56):

I thought about that. I don't love it because I can't see a reason that invoking a POF fn should warn

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:56):

i.e., that covers the first half..

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:56):

The second warning would of course not be possible in the general function-pointer case

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:56):

right

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:56):

that's why I said it's imprecise

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:57):

the first has false warnings, the second has missed warnings

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:58):

for the first, it would warn on calls to function pointers and to other #[longjmp] functions, but not to normal functions, correct?

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:59):

I suppose

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:59):

Yeah, I guess that's true

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:59):

I was thinking it should warn on anything but I guess that's over-approximated

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:00):

And since they're only warnings, they can be made more precise in the future once we have the ability to add annotations to function pointers

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:01):

if/when

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:01):

yeah, seems reasonable

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:01):

I geuss we could try to just add this into the RFC

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:02):

but it also feels like a "separate thing" in its own way

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:04):

(but this feels pretty good to me, all things considered)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:04):

I think we can revise the RFC to say that longjmp over POFs is TBD

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:04):

and otherwise definitely UB

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:04):

yeah, this is I think the right thing to do

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:05):

I actually really like the idea (if not the name) of the #[longjmp] annotation. It enables us to give a much more precise answer to the question "when do destructors not execute", I think.

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:05):

Yes. And I think it'd be really great to be able to assist people in constructing POF functions

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:08):

Agreed

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:09):

So, we now have more action items!

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:10):

returning to the other one, the quesiton is, should we try to start a thread on the LLVM internals?

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:10):

(I don't know that it's a blocker, that could happen concurrently with the RFC)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:10):

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:15):

So, that resolves the third bullet-item from our original list, about optimizations that could be broken by longjmp

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:15):

Want to discuss this one?

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:17):

this is somewhat entangled with the other point

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:18):

that is, the only way I know of to "not execute a dtor" is basically to longjmp

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:18):

or otherwise deallocate frames

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:22):

I wrote up the idea of a longjmp fn here btw: https://github.com/rust-lang/project-ffi-unwind/issues/30

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:22):

Right, so presumably, along with introducing #[longjmp], we'd formally specify that it is UB to skip destructors in non-#[longjmp] frames

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:22):

(btw my current idea for the actual name of the annotation is #[cancelable])

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:23):

I think btw I would be happy to change the "it is UB to deallocate a frame without running a dtor" to a more naunced explanation that says how deallocating frames without running destructors can cause UB and is not something you can do unless you control all the frames

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:23):

But I still think we need a pithy term for that kind of behavior

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:23):

which is basically UB

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:23):

I guess it is reminiscent of the terms that Ralf introduced of "language invariant" vs "library invariant"

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:23):

fair enough, but I think we can also flatly prohibit skipping destructors in frames that aren't annotated "cancelable"

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:23):

er, validity

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:24):

yes, I think we can do that as well

view this post on Zulip nikomatsakis (Jun 11 2020 at 18:24):

(which is what I meant by they are entangled; presumably if we do that, it's enough)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 18:37):

Okay, it sounds like we've got a plan. Anything else?

view this post on Zulip nikomatsakis (Jun 11 2020 at 19:01):

(Nope) :)

view this post on Zulip BatmanAoD (Kyle Strand) (Jul 16 2020 at 17:32):

@WG-ffi-unwind Biweekly check in!

view this post on Zulip BatmanAoD (Kyle Strand) (Jul 16 2020 at 17:38):

We have one open suggestion on the RFC, which is to use "C-unwind" instead of "C unwind". https://github.com/rust-lang/rfcs/pull/2945#discussion_r454644725

view this post on Zulip BatmanAoD (Kyle Strand) (Jul 16 2020 at 17:41):

We also have three outstanding lang team members who haven't approved the RFC yet; I'm not sure if they should be pinged at this point.

view this post on Zulip nikomatsakis (Jul 16 2020 at 18:44):

I don't really have an opinion about "C-unwind" vs "C unwind" vs whatever else

view this post on Zulip nikomatsakis (Jul 16 2020 at 18:45):

I think the argument that people may think they can reorder the words in the string is...true but seems like a stretch

view this post on Zulip nikomatsakis (Jul 16 2020 at 18:46):

early on there was a proposal C+unwind or something but I guess that was scrapped because it resembled C++?

view this post on Zulip nikomatsakis (Jul 16 2020 at 18:46):

also, sorry I missed today's meeting at the proper time, got double schedule :/

view this post on Zulip BatmanAoD (Kyle Strand) (Jul 16 2020 at 20:11):

No problem. Yes, I think C++ was the main reason we opted for a space instead of punctuation.

view this post on Zulip acfoltzer (Jul 16 2020 at 21:45):

catching up late, apologies; been in meetings for four hours :disappointed_relieved: my main check-in item is to point out this new topic about Fastly providing implementation effort: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/coordinating.20on.20implementation

view this post on Zulip acfoltzer (Jul 16 2020 at 21:46):

I am still neck-deep in other parts of the product, but fortunately the team has grown substantially since we began this unwinding effort, so we have the bandwidth to help out

view this post on Zulip acfoltzer (Jul 30 2020 at 17:36):

hey folks, I don't have much to add this meeting except a hearty congratulations for the RFC soon being merged :tada:

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 13 2020 at 17:36):

@WG-ffi-unwind

Weekly meeting! (A few minutes late; just got the calendar notification for some reason.)

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 13 2020 at 17:38):

I'll keep it brief again. I know there's a lot going on, and I don't know how much that will impact us. Also, Niko requested that we take something of a break after the RFC merged, so I don't want to do any actual spec-work today.

view this post on Zulip acfoltzer (Aug 13 2020 at 17:38):

:wave: I don't have much to report this time around. I believe @katelyn martin has been heads down in some internal stuff as well. I guess my main contribution is :heart: to Niko and the other folks impacted by this week's news

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 13 2020 at 17:39):

Thanks for calling that out. :blue_heart: from me as well.

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 13 2020 at 17:44):

Looks like there are two @katelyn martin Zulip members? I'm adding @Katelyn Martin

I will add both to the FFI group for now, since I am assuming they both belong to the same real-life person.

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 13 2020 at 17:45):

(Katelyn, for context: we have a biweekly meeting here in Zulip; I believe Niko can add you to the calendar event if you wish)

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 13 2020 at 17:47):

I think that's all I wanted to do/say for today, other than to reiterate that our next "specification" effort should be around longjmp/thread-canceling. I think this can happen in parallel with Katelyn's implementation work.

view this post on Zulip nikomatsakis (Aug 17 2020 at 17:45):

:wave:

view this post on Zulip nikomatsakis (Aug 17 2020 at 17:45):

as y'all probably surmised I was a bit "under the weather" last week

view this post on Zulip nikomatsakis (Aug 17 2020 at 17:45):

this coming Thursday is RustConf

view this post on Zulip katelyn martin (Aug 18 2020 at 15:47):

:wave: Hello! I've been a bit occupied with things, sorry about that. I would love to be added to the calendar invite! I'll also echo the :heart: regarding recent news.

view this post on Zulip nikomatsakis (Aug 19 2020 at 20:50):

@katelyn martin I can add you to the meeting invite

view this post on Zulip nikomatsakis (Aug 19 2020 at 20:50):

but if you want to arrange a separate time to dig in a bit, feel free to privmsg me

view this post on Zulip katelyn martin (Aug 19 2020 at 20:54):

@nikomatsakis Invitation received, thank you! I also appreciate the invitation to dig in further as well

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:31):

Hey y'all, we have a meeting now =) I've been quite distracted, but is anyone around?

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:31):

In particular, @katelyn martin, if you wanted to talk about impl stuff

view this post on Zulip katelyn martin (Aug 27 2020 at 17:32):

:wave: Hi everybody. I started working on implementing the RFC this week.

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:32):

Great news

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:32):

Did you wind up with any questions?

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:32):

I am 100% behind on github notifications, so if you left comments there I for sure didn't see them

view this post on Zulip katelyn martin (Aug 27 2020 at 17:33):

Hello! :wave: Oops, just posted over in the weekly meeting topic.

I started working on the RFC this week. At this point I've been looking around through the code you linked in the tracking issue. Thank you once again, these were all excellent leads!

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 27 2020 at 17:34):

@WG-ffi-unwind Bi-weekly check-in! Sorry I'm a few minutes late.

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:34):

lol, no worries, I actually think this group is just using the "weekly meeting" topic

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:34):

vs separate topics per meeting

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:34):

so it's really my bad

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:34):

I'll rename :)

view this post on Zulip katelyn martin (Aug 27 2020 at 17:34):

Ah! I'll redirect over there :fish: :)

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:36):

Anyway :) as I was saying, my main thought at the moment was whether I could help in any way with impl effort, but @BatmanAoD (Kyle Strand) not sure if you had other things you wanted to talk about?

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 27 2020 at 17:37):

I think the implementation is the most important thing right now, but I do want to get a read on who's feeling ready to start talking more about stack-cancelation.

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 27 2020 at 17:37):

I.e. longjmp/pthread_exit

view this post on Zulip katelyn martin (Aug 27 2020 at 17:38):

I don't think I'm far enough along for this question to be urgent yet, but you mentioned guiding the nounwind attribute on callsites (see: https://github.com/rust-lang/rust/blob/cfdf9d335501cc0a53ae69c940095cca7d4be0f8/src/librustc_codegen_llvm/abi.rs#L399-L402)

I'm _definitely_ still getting a lay of the land (and trying to get my tools to agree with x.py :sweat_smile:) but that's the part where I feel the most unknown.

view this post on Zulip Amanieu (Aug 27 2020 at 17:38):

Talking about impl stuff, did we ever decide what to do about #70212?

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:40):

katelyn martin said:

I don't think I'm far enough along for this question to be urgent yet, but you mentioned guiding the nounwind attribute on callsites (see: https://github.com/rust-lang/rust/blob/cfdf9d335501cc0a53ae69c940095cca7d4be0f8/src/librustc_codegen_llvm/abi.rs#L399-L402)

I'm _definitely_ still getting a lay of the land (and trying to get my tools to agree with x.py :sweat_smile:) but that's the part where I feel the most unknown.

ok -- so the nounwind attribute is used by LLVM to indicate functions that cannot unwind. We would expect to apply it to Rust functions with the "C" ABI (e.g.,

extern "C" fn foo() { }

and probably also external functions with C ABI.

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:40):

@Amanieu I thought we decided to abort for now

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 27 2020 at 17:42):

The main thing the RFC guarantees is that the implementation must not place nounwind on a "C-unwind" boundary unless there's some way to guarantee that the function actually won't unwind. I think that panic=abort might be sufficient for that guarantee on function definitions written in Rust, but that's not the case for extern declarations.

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:44):

I don't remember, @katelyn martin, did we ever write down like "what attributes we expect on which functions and when"

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:44):

I was thinking that this would be a good exercise at some point

view this post on Zulip katelyn martin (Aug 27 2020 at 17:45):

@nikomatsakis Do you mean this table in the RFC by any chance? https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#abi-boundaries-and-unforced-unwinding

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:45):

well, that is pretty close to what I meant

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:45):

and maybe it just suffices :)

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:46):

I was thinking that from an impl POV it'd be good to have test cases for each case basically and a kind of checklist

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:46):

(and maybe actually creating such tests is a good first step towards implementing)

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 27 2020 at 17:47):

I agree. The table implies restrictions on when nounwind is appropriate, but I don't think it's quite comprehensive from an implementation standpoint.

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:48):

I think the main difference between that table and what I was imagining is that it describes the behavior we want, and I was thinking more from an impl focused pov -- i.e., what LLVM attributes should be present, etc

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:48):

let me just go review what we wrote in the issue

view this post on Zulip katelyn martin (Aug 27 2020 at 17:48):

https://github.com/rust-lang/rust/issues/74990 here's the tracking issue :)

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 27 2020 at 17:48):

Additionally, tests would be valuable so that in the future, if there are improvements to the optimization logic for guaranteeing that an unwind is actually impossible (which makes nounwind appropriate even for "C-unwind" functions), the exact behavior of those optimizations can be added to the test suite.

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:49):

I guess that the "implementation notes" was my attempt at this

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:49):

there is some documentation on writing tests in the rustc-dev-guide

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:50):

the idea would be to make ui tests here

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:50):

and to use some of the // comments to force command-line options like -Cpanic=abort etc

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:51):

(see the header comments section)

view this post on Zulip katelyn martin (Aug 27 2020 at 17:51):

handy, thank you for that!

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:54):

OK, well, if you have any other questions as you go definitely just leave them

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:54):

and feel free to ping if I don't answer ;)

view this post on Zulip katelyn martin (Aug 27 2020 at 17:55):

definitely! thank you for the guidance, it's much appreciated. :heart:

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 27 2020 at 17:56):

Re: nounwind on callsites: it looks like we don't yet apply nounwind to any callsites; if this is the case, then any change to callsites is purely an optimization.

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 27 2020 at 17:57):

So I think it's not necessary for the initial implementation.

view this post on Zulip nikomatsakis (Aug 27 2020 at 17:57):

yeah that's true

view this post on Zulip katelyn martin (Sep 10 2020 at 17:30):

Hello again everyone!

I have been making some more progress on implementing RFC 2945. I have opened a
draft PR containing my work so far here: https://github.com/rust-lang/rust/pull/76570

At this point, I have started working on the changes to codegen. I don't have
these changes pushed to that branch quite yet, since that work is still being
drafted on my end. I'm currently working on adding more tests to the
src/tests/codegen suite. To do that, I've been referring to the LLVM
documentation on FileCheck here: https://llvm.org/docs/CommandGuide/FileCheck.html

I've been a bit caught up with some work tasks, so between that and the recent
U.S. holiday weekend, I don't have too much else to include in my update today.

I'm making progress though, and don't have further questions at this
time. Thanks for the wonderful mentorship and support so far, I appreciate you
all!

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 10 2020 at 17:36):

@WG-ffi-unwind Thanks Katelyn!

Does anyone else have anything specific to bring up?

view this post on Zulip acfoltzer (Sep 10 2020 at 17:40):

I just fixed an FFI unwinding UB bug in Lucet :laughing: it was my own dang fault though, rather than something that needs the new ABI https://github.com/bytecodealliance/lucet/pull/584

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 10 2020 at 18:00):

I'd like to have a rough plan for moving forward on the POF/cancellation discussion, but I don't really have a sense of how to do that. I think we need to know:

Over the next two weeks, I think I will start trying to update the project repository to reflect the shift in focus toward POF/cancellation.

view this post on Zulip nikomatsakis (Sep 14 2020 at 16:58):

Sorry for missing meeting y'all, I was taking a long weekend and forgot to let y'all know

view this post on Zulip nikomatsakis (Sep 14 2020 at 16:58):

@BatmanAoD (Kyle Strand) I'm still fairly busy but not opposed to starting to open that discussion

view this post on Zulip nikomatsakis (Sep 14 2020 at 16:59):

I think writing a blog post as a way to frame the discussion is a good idea regardless, as editing it may help us to achieve more internal alignment amongst ourselves (and to communicate with lang team)

view this post on Zulip katelyn martin (Sep 24 2020 at 17:31):

:wave: Hey folks! I don't have any updates for this weekly meeting. My apologies, work & the general state of the planet have been occupying more than their fair share of brain cycles. :blue_heart: :pensive: I'm hoping to set some time aside next week to make further progress, now that I have set up some proper codegen tests for the c_unwind feature gate.

I'll cede the floor for discussion about the other plans, regarding POF/cancellation & a blog post, that were described above in the previous meeting.

view this post on Zulip nikomatsakis (Sep 24 2020 at 17:32):

Hey @katelyn martin

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 24 2020 at 17:32):

@WG-ffi-unwind Hi all! Apologies, I haven't done anything for the group since the last meeting. I do plan to draft a blog post before our next meeting, though.

view this post on Zulip nikomatsakis (Sep 24 2020 at 17:33):

I was just thinking I could take a look at your PR

view this post on Zulip nikomatsakis (Sep 24 2020 at 17:33):

I've not done anything related to this :)

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 24 2020 at 17:33):

@katelyn martin No worries re: minimal update. You are clearly not alone!

view this post on Zulip katelyn martin (Sep 24 2020 at 17:36):

It's open as a draft here: https://github.com/rust-lang/rust/pull/76570

Right now I've just set up the scaffolding for it, following the instructions from the rustc developer guide. Feature flag, and UI tests to make sure that this is properly gated. The should_abort_on_panic changes and so forth haven't been worked out yet.

The main changes of note there are the adjustments to the Abi enum. I elected to use a boolean payload rather than add more variants, since the RFC allows for more unwinding ABI's to be added in the future.

view this post on Zulip katelyn martin (Sep 24 2020 at 17:37):

I'll need to rebase it soon, as some conflicts have popped up, but reviews are certainly welcome!

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 24 2020 at 17:47):

I took a brief look at it and, as far as I understood it (I haven't personally done any work in the compiler before), it looked like a good start. I suspect the implementation of the actual change re: the nounwind attribute will go pretty quickly.

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 24 2020 at 17:48):

Anyway, I don't have anything else to discuss, and I've been thinking that I should start "officially" calling these meetings to a close so that any further discussion can be considered async. Thanks, you two!

view this post on Zulip katelyn martin (Nov 05 2020 at 18:30):

Howdy! Nothing too much to report. I'm still working to address the PR review that Niko was kind enough to leave. Wonderful points, and I'm excited to keep plugging away at this.

view this post on Zulip nikomatsakis (Nov 05 2020 at 18:34):

@katelyn martin great!

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 05 2020 at 18:34):

:wave:

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 05 2020 at 18:34):

I outlined the blog post but did not turn that outline into prose yet.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 19 2020 at 18:30):

@WG-ffi-unwind Bi-weekly check-in! I finally have a draft to share: https://github.com/rust-lang/project-ffi-unwind/pull/33/files

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 19 2020 at 18:31):

There are several TODO/TBD items in there

view this post on Zulip nikomatsakis (Nov 19 2020 at 18:34):

oh, nice

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 19 2020 at 18:34):

@katelyn martin one of them is specifically a question for you: there's a link to your in-progress PR, and if you don't mind the publicity, I'd like to name you specifically as the person working on it.

view this post on Zulip katelyn martin (Nov 19 2020 at 18:34):

Absolutely! I don't mind that at all :blush:

view this post on Zulip nikomatsakis (Nov 19 2020 at 18:34):

/me reads

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 19 2020 at 18:35):

seems I opened the branch on the origin repo again... :face_palm:

view this post on Zulip nikomatsakis (Nov 19 2020 at 19:29):

@BatmanAoD (Kyle Strand) left some comments!

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 19 2020 at 19:29):

Thanks!

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 27 2020 at 00:47):

I have revised my draft.

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 03 2020 at 18:31):

@WG-ffi-unwind Bi-weekly check-in! I have updated my draft, and think it might be ready to open as a PR on the Inside Rust blog.

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 03 2020 at 18:31):

https://github.com/rust-lang/project-ffi-unwind/pull/33

view this post on Zulip katelyn martin (Dec 03 2020 at 18:47):

I'm working on the rest of my PR today! I'm hoping to have it wrapped up by Friday.

Thank you everybody for your patience, and apologies for letting this one drag on longer than I wanted it to. :blue_heart:

view this post on Zulip nikomatsakis (Dec 07 2020 at 21:34):

/me reads

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 10 2020 at 18:40):

@nikomatsakis should I merge my PR and open it as a PR on the Inside Rust blog?

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 11 2020 at 01:08):

@WG-ffi-unwind I will not be able to make it next Thursday; feel free to sync without me. I will open a PR on the Rust Insiders blog repo whenever Niko thinks it's ready.

view this post on Zulip nikomatsakis (Dec 11 2020 at 10:50):

I can't really make it until the end of the year, but I think merging your PR is good

view this post on Zulip nikomatsakis (Dec 11 2020 at 10:50):

will do

view this post on Zulip katelyn martin (Dec 14 2020 at 21:40):

In exciting news, I've now marked https://github.com/rust-lang/rust/pull/76570 (Implement RFC 2945: "C-unwind" ABI) as ready for review! The git history is all tidied up, and I've addressed all of the initial feedback that was kindly provided. Thank you everybody for the guidance, and for the opportunity to implement this. :tada: :blush:

view this post on Zulip nikomatsakis (Dec 15 2020 at 13:39):

@katelyn martin great!

view this post on Zulip katelyn martin (Dec 17 2020 at 18:36):

Greetings! I don't have any news besides the message above, PR 76570 is ready for review. I'll cede my time to the blog repo, or any other topics people might want to talk about. :smiley_cat:

view this post on Zulip nikomatsakis (Dec 17 2020 at 18:50):

Ack!

view this post on Zulip nikomatsakis (Dec 17 2020 at 18:51):

I'm pretty slow today anyway

view this post on Zulip nikomatsakis (Dec 17 2020 at 18:51):

I have to merge and prepare that blog post, though I may not get to that until next week

view this post on Zulip katelyn martin (Dec 17 2020 at 18:51):

I'm pretty slow today anyway

Very understandable! The holidays are quickly approaching :snowflake:

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 17 2020 at 19:21):

@nikomatsakis the blog post is already merged to our repo; do you mean merge & prepare it in the Inside Rust repo? I haven't opened a PR for that yet but I will do so now.

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 17 2020 at 19:26):

https://github.com/rust-lang/blog.rust-lang.org/pull/743

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 17 2020 at 19:32):

I put an "XX" in the date because I don't know when this will be published, so the CI check is failing.

view this post on Zulip BatmanAoD (Kyle Strand) (Dec 31 2020 at 18:48):

I'm on vacation and completely forgot about the weekly check-in. Happy Gregorian New-Year's Eve!

view this post on Zulip katelyn martin (Jan 14 2021 at 18:26):

Howdy! I don't have any pressing updates. I bumped into a spurious CI problem, but in the meantime another merge conflict has come up. I'll address that, and hopefully CI can do its thing this time around. Pardon the delay :grimacing:

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 14 2021 at 18:36):

@WG-ffi-unwind I also don't have any updates. Niko, what is the next step for the blog post PR? https://github.com/rust-lang/blog.rust-lang.org/pull/743

view this post on Zulip nikomatsakis (Jan 15 2021 at 17:14):

@BatmanAoD (Kyle Strand) ugh the status is that I was overloaded and completely forgot. i'm adding to my (newly created) todo list :)

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 15 2021 at 17:18):

I understand - I saw your tweet declaring notification bankruptcy! Just let me know if/when there's anything I can do to move things forward.

view this post on Zulip katelyn martin (Jan 28 2021 at 15:18):

exciting news; rust-lang/rust#76570 (_implementing RFC 2945_) has been approved and is now waiting on Bors! :tada:

I am new to the Rust repo, but as I understand it this means it will be rolled up and merged soon? In any case, thanks to everybody for giving the opportunity to do this. It was a lot of fun :smile:

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 28 2021 at 15:53):

Excellent! Thanks for seeing that through!

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 28 2021 at 18:35):

@WG-ffi-unwind Bi-weekly sync! Sounds like we have two major updates:

view this post on Zulip BatmanAoD (Kyle Strand) (Jan 28 2021 at 18:42):

I am not sure what the next steps are on longjmp following the blog post. I was hoping we'd get a bit of a response from the community regarding whether the annotations sound like a reasonable limitation on longjmp, but I doubt we'll get much of that.

view this post on Zulip nikomatsakis (Jan 28 2021 at 21:29):

@BatmanAoD (Kyle Strand) sorry -- I am in a bunch of meetings so not very responsive -- I think the next steps are probably to prepare a draft RFC with "bullet points" more than prose

view this post on Zulip nikomatsakis (Jan 28 2021 at 21:29):

and maybe we can schedule a lang team design meeting to review it

view this post on Zulip nikomatsakis (Jan 28 2021 at 21:29):

it seemed to me that we were pretty close to a design

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:00):

@WG-ffi-unwind Sorry all, stopped watching the clock for a bit and got distracted.

The C-unwind implementation PR has some merge conflicts, but is otherwise looking good (1 approval and CI was green at one point).

I have to admit that the complete lack of response to the blog post makes me wonder how high a priority longjmp actually is.

view this post on Zulip nikomatsakis (Feb 11 2021 at 19:00):

Heh

view this post on Zulip nikomatsakis (Feb 11 2021 at 19:00):

I was thinking to myself

view this post on Zulip nikomatsakis (Feb 11 2021 at 19:00):

how badly do I want to invest time in this discussion :)

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:01):

I'm also wondering how bad it would be if we just specified "longjmp is guaranteed to work over POFs" and left it at that. This seems like the "obvious" way it should work, and effectively how it works today.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:03):

The benefits of adding a new annotation to the language seem fairly niche: the optimzation we'd previously talked about that could be enabled seems...obscure...and I have no sense of how much (if at all) it would actually improve code quality in any specific case.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:05):

Compiler warnings are always nice, but on the other hand, having explicit support for "cancelable" frames seems like taking an unfortunate ecosystem wart and making it seem more like a first-class language feature. I really don't want to inadvertently cause people to use longjmp _more_ because there exists an annotation for it.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:12):

E.g. I can imagine someone recommending longjmp instead of panic for performance in some specific use-case and citing the existence of a "cancelable" annotation as evidence that this is a good practice.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:12):

And I don't want that!

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:14):

Maybe the annotation should be

#[watch-out-some-legacy-C-constructs-are-leaking]

view this post on Zulip Amanieu (Feb 11 2021 at 19:34):

I'm tending towards just allowing longjmp.

view this post on Zulip Amanieu (Feb 11 2021 at 19:36):

It seems to me that any optimizations that #[pof-longjmp] might enable can already be done using escape analysis.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:47):

The concern, really, is that the compiler wouldn't know about longjmp, isn't it?

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 11 2021 at 19:47):

I suppose that if cross-language LTO is used, it would be able to see longjmps and cancels...

view this post on Zulip Amanieu (Feb 11 2021 at 20:15):

The compiler should assume a longjmp may happen and optimize accordingly.

view this post on Zulip Amanieu (Feb 11 2021 at 20:15):

LLVM already assumes this for Clang.

view this post on Zulip Amanieu (Feb 11 2021 at 20:16):

The question is, what specific optimization would be enabled by assuming longjmp doesn't happen?

view this post on Zulip bjorn3 (Feb 11 2021 at 20:18):

With stacked borrows it may be possible to delay updating the value pointed to by references or speculatively update them across function calls. longjmp would make this impossible.

view this post on Zulip Amanieu (Feb 11 2021 at 20:18):

AFAIK the only thing that it allows is moving things from before the call to after it. This is only possible if the things that are moved are not externally observable (i.e. escape analysis). However if these things are not externally observable then it doesn't matter if they don't happen when longjmp is called.

view this post on Zulip Amanieu (Feb 11 2021 at 20:19):

By "externally" I mean to the caller of the current function.

view this post on Zulip bjorn3 (Feb 11 2021 at 20:22):

Allowing all calls to longjmp would make the code movement of section 4.2 of https://www.ralfj.de/blog/2018/08/07/stacked-borrows.html illegal.

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 23 2021 at 22:31):

@WG-ffi-unwind I won't be available during our typical sync-up time this Thursday; would 11am-11:30 work?

view this post on Zulip nikomatsakis (Feb 24 2021 at 11:01):

BatmanAoD (Kyle Strand) said:

Compiler warnings are always nice, but on the other hand, having explicit support for "cancelable" frames seems like taking an unfortunate ecosystem wart and making it seem more like a first-class language feature. I really don't want to inadvertently cause people to use longjmp _more_ because there exists an annotation for it.

I disagree mildly with this-- I think this is a first-class interop feature, not a wart.

view this post on Zulip nikomatsakis (Feb 24 2021 at 11:02):

However, I think it would be ok for it to be enabled via something like an allow-by-default lint

view this post on Zulip nikomatsakis (Feb 24 2021 at 11:02):

bjorn3 said:

Allowing all calls to longjmp would make the code movement of section 4.2 of https://www.ralfj.de/blog/2018/08/07/stacked-borrows.html illegal.

this

view this post on Zulip nikomatsakis (Feb 24 2021 at 11:02):

let's fork out this escape analysis discussion

view this post on Zulip nikomatsakis (Feb 24 2021 at 11:03):

I guess we already have #project-ffi-unwind > cost of supporting longjmp without annotations

view this post on Zulip nikomatsakis (Feb 24 2021 at 11:06):

BatmanAoD (Kyle Strand) said:

@WG-ffi-unwind I won't be available during our typical sync-up time this Thursday; would 11am-11:30 work?

I am not available tomorrow at all :(

view this post on Zulip katelyn martin (Feb 24 2021 at 19:35):

:wave: Howdy!

The implementation PR got stuck in rollup last time around. I believe I've now fixed the problems that caused that, and addressed the merge conflicts that had popped up. I've pinged Amanieu in that PR for another review pass, so hopefully we'll be able to land this soon. :tada:

I'll send a follow-up message when that does land, but wanted to go ahead and send a message about this before the weekly meeting.

view this post on Zulip nikomatsakis (Feb 24 2021 at 20:31):

@katelyn martin good to know! I was wondering if it had landed yet

view this post on Zulip katelyn martin (Feb 24 2021 at 20:32):

I'll keep my fingers crossed for no more rollup surprises this time around :innocent:

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 25 2021 at 00:15):

@WG-ffi-unwind Since there's been quite a bit more activity here recently, but Niko can't make it tomorrow, could we possibly reschedule for early next week?

view this post on Zulip katelyn martin (Feb 25 2021 at 18:31):

Howdy! :wave: :cowboy:

No exciting updates here, really. The implementation PR is waiting for rollup, I fixed a silly mistake surrounding // ignore-* directives in some of the unit tests, so we should be in good shape now. Thanks again to @Amanieu for prompt reviews on this work, I really appreciate it.

If all goes well, that should be landing very soon. :tada:

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 25 2021 at 18:45):

Hey Katelyn! Thanks again for your work on this. I'm very excited to see it land.

I don't think we have much else to discuss here at the sync-up; I want to see the async discussions around longjmp and pthread_cancel continue for a bit before we make more decisions on how to proceed.

view this post on Zulip katelyn martin (Mar 10 2021 at 20:50):

https://github.com/rust-lang/rust/pull/76570 has been merged! :tada:

view this post on Zulip katelyn martin (Mar 11 2021 at 18:27):

I've got nothing to report; as mentioned above the implementation PR has landed. That's probably all from me for the time being, but I want to take a moment to thank you all again for providing the opportunity to work on this RFC! It was a lot of fun contributing to rustc for the first time, and you all made that an excellent experience.

Feel free to ping me if anything else comes up! :black_heart: :sparkles:

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:32):

@WG-ffi-unwind Hi all! I believe we actually do have a few things to discuss today.

First off, congratulations and thanks again to Katelyn! I was thrilled to see that PR get merged, and I hope you were too.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:32):

The other things I think we should discuss briefly are:

view this post on Zulip katelyn martin (Mar 11 2021 at 18:33):

Ah! Here's one other little detail: https://github.com/rust-lang/rust/issues/63943 I believe this issue can now be closed, but I'd cede to what others think about that. :smile:

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:34):

We definitely need to resolve the issue; but yes, now that "C-unwind" exists, it should be unblocked.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:36):

I don't actually want to be the one to say "yes, that's done" because to be honest I do not feel like an expert in that regard and (confession) I never closely reviewed the PR code.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:40):

With the new behavior from the "C-unwind" PR, it is now the case that panicking out of a "C" function always aborts (when it would previously escape the function boundary), correct?

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:41):

If so, I think that resolves the bug as written.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:42):

If I'm reading it correctly, the test case in the issue description should have a 0 exit code if "C" is changed to "C-unwind" and the unreachable_unchecked is removed.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:46):

The other follow-up issues I wanted to ask about are:

view this post on Zulip katelyn martin (Mar 11 2021 at 18:56):

With the new behavior from the "C-unwind" PR, it is now the case that panicking out of a "C" function always aborts (when it would previously escape the function boundary), correct?

_Almost_, to be slightly pedantic an extern "C" with #[unwind(allowed)] attribute would also unwind. That ought to be functionally equivalent to extern "C-unwind". I responded that yes, that can be closed now AIUI.

Katelyn, do you have any interest in taking this refactoring on? https://github.com/rust-lang/rust/issues/65303#issuecomment-796566196

Just when i thought i was out... they pull me back in! I'd be happy try and take that on! I certainly found that duplicate logic a smidge confusing myself.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:57):

That ought to be functionally equivalent to extern "C-unwind"

I think as long as nounwind is not emitted, there's no unsoundness, correct?

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:57):

So yes, I would agree that the bug can be closed. Though that brings up one of the follow-ups I forgot to mention! We do need to deprecate & remove unwind(allowed|denied).

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:58):

I am wondering if the code-duplication issue can be combined with removing those annotations.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 18:59):

Do you think it would be easier to do as a single effort, or separately?

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 19:01):

Anyway, sorry, I need to jump to another meeting. Feel free to continue the discussion here async; I'll check back regularly.

view this post on Zulip katelyn martin (Mar 11 2021 at 19:06):

I am wondering if the code-duplication issue can be combined with removing those annotations.
Do you think it would be easier to do as a single effort, or separately?

My gut says that doing these separately would probably be most sensible, but I haven't tugged on the relevant strings enough to know for sure. We could operate under the assumption that these are separate efforts until proven wrong.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 19:26):

:+1:

view this post on Zulip katelyn martin (Mar 11 2021 at 19:41):

What are the next steps for stabilization & feature-gate removal?

Oh and _this_ part I have very little idea about. I don't have an answer, and will let someone else with more familiarity around stabilization answer that question. :smile:

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 11 2021 at 19:47):

@nikomatsakis ^ do you have guidance on stabilization & feature-gate removal?

view this post on Zulip nikomatsakis (Mar 20 2021 at 11:29):

katelyn martin said:

Oh and _this_ part I have very little idea about. I don't have an answer, and will let someone else with more familiarity around stabilization answer that question. :smile:

So, the next steps from a procedural POV is to write-up a stabilization report -- but we do need to let the feature bake a bit

view this post on Zulip nikomatsakis (Mar 20 2021 at 11:29):

we don't have a good process for this right now -- like a clear way to "set a timer" sort of thing --

view this post on Zulip nikomatsakis (Mar 20 2021 at 11:29):

I think it'd be really helpful to collect some experience reports from people adopting it

view this post on Zulip nikomatsakis (Mar 20 2021 at 11:29):

although of course there is always the challenge that adopting it riquires adopting nightly

view this post on Zulip nikomatsakis (Mar 20 2021 at 11:29):

one thing we might do is write a blog post encouraging adoption and encouraging people to leave comments on the tracking issue -- what do you think about that, @katelyn martin or @BatmanAoD (Kyle Strand) ?

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 20 2021 at 18:26):

@nikomatsakis I agree with that, so I've included it in a summary I just wrote up of our next steps

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 17:35):

@WG-ffi-unwind Hi all! (Sorry I'm a few minutes late.)

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 17:37):

I think the main thing for today is making a decision on how to proceed with the Beta branch issue (the current Beta cut includes the changes from the PR, which changes the behavior of "C" without providing an opt-out).

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 17:39):

The options we've discussed are:

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 17:39):

Additionally, I think we need to give the release team a heads up on this.

view this post on Zulip katelyn martin (Mar 25 2021 at 17:40):

Hello! Apologies, I haven't had much time this week to properly focus on FFI-unwind this week. As I understand it, the steps are to first place the change in behavior of the C ABI behind the feature gate, and then work on addressing the soundness guarantees after that's accomplished.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 17:41):

Do you mean without the feature gate? The time-sensitive requirement here is to not land a breaking change on Stable.

view this post on Zulip katelyn martin (Mar 25 2021 at 17:43):

Pardon. Yes, I meant that the change in behavior would not apply without the feature gate.

view this post on Zulip katelyn martin (Mar 25 2021 at 17:45):

Time-sensitivity is good to know about; can I ask what the general time scale is? Worst case, reverting that PR in the beta branch might be a fine route forward for now.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 17:45):

The stable release should be 6 weeks from the beta cut, which I believe was last weekend. I'll double-check the dates though

view this post on Zulip simulacrum (Mar 25 2021 at 17:53):

yeah, that's correct

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 17:57):

...or rather, the stable release should be every 6 weeks, and today is a stable release day. I didn't realize the beta was cut earlier than that.

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 17:58):

So I think we have 6 weeks from today

view this post on Zulip katelyn martin (Mar 25 2021 at 18:03):

Gotchya. I think I would be able put together a fix for that in < 2 weeks. Accounting for a bit of buffer time for review / rollup, I think we can have that fixed in time. But, if that ends up taking more than... say 4 weeks? I'd be content to play it safe and revert the PR before the next cut

view this post on Zulip katelyn martin (Mar 25 2021 at 18:04):

Does that feel like a fair set of deadlines to you?

view this post on Zulip simulacrum (Mar 25 2021 at 18:05):

Ideally we want the PR merged into beta branch roughly 2 weeks out from the thursday release day, so that sounds like a reasonable timeline

view this post on Zulip BatmanAoD (Kyle Strand) (Mar 25 2021 at 18:06):

I asked for a deadline in the release team channel, so I'll leave it up to them; but yes, I would expect them to agree that that's a reasonable timeline.

view this post on Zulip katelyn martin (Mar 25 2021 at 18:10):

Awesome thank you all, and sorry about the trouble! :sweat_smile:

view this post on Zulip katelyn martin (Apr 08 2021 at 16:55):

:wave: I'll be a bit async for this weekly meeting, I have some errands to run today

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 08 2021 at 16:56):

@katelyn martin were you able to work on a patch for the "C" behavior?

view this post on Zulip katelyn martin (Apr 12 2021 at 17:17):

Hi @BatmanAoD (Kyle Strand)!

Addressing the points you've made here in the "_next steps_" channel is going to be my main focus for the next few days. I spent some time looking into the abort-on-unwind wrapper; that part in particular I'm not entirely sure about yet. I think I have found the right places to look around, but in general I'm a bit new to these corners of rustc.

As for the patch, I'm going to put that together today. That part in particular ought not to be as involved as the rest of the work, and given the urgency, I don't want to wait any longer on that.

My sincere apologies for making you wait over the weekend! :blue_heart:

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 12 2021 at 21:56):

katelyn martin said:

I spent some time looking into the abort-on-unwind wrapper; that part in particular I'm not entirely sure about yet.

Yeah, that's one bit of what we spec'd in the RFC that I suspect is unfortunately rather tricky at the implementation level. It may even be introducing a new concept to the compiler (AFAIK there's no existing feature that requires auto-generating shims like that).

As for the patch, I'm going to put that together today.

Excellent! I don't know if I'll be online again today, but please ping @wg-ffi-unwind when you've opened a PR, and tomorrow morning I'll provide an update to the release team. (Or, if you'd like, you can just post a link to the PR in the topic in their stream, #t-release.)

view this post on Zulip katelyn martin (Apr 13 2021 at 14:33):

Cross posting from #project-ffi-unwind > "C-unwind" next steps...

Hi @WG-ffi-unwind! I've opened up https://github.com/rust-lang/rust/pull/84158, which should address the concerns above.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 22 2021 at 17:30):

@WG-ffi-unwind Check-in meeting time!

view this post on Zulip Amanieu (Apr 22 2021 at 17:34):

I haven't gotten around to opening an issue for the willreturn bug. I've had a pretty hectic week.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 22 2021 at 17:36):

Status updates:

view this post on Zulip katelyn martin (Apr 22 2021 at 17:41):

:wave: Hiya. I've had a hectic week, and haven't been able to keep abreast of much aside from landing the "C" behavior fix. That's unfortunate news to hear :sad: Is there anything I should be aware of, or that I can do to help?

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 22 2021 at 17:46):

^ actually I'm mistaken; your patch was already merged to master, so it's only this upcoming release that's affected by the revert.

view this post on Zulip katelyn martin (Apr 22 2021 at 17:53):

:bulb: Oh! I suppose that makes a bit more sense. Apologies again for the delay in preparing that patch, and thank you for clarifying.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 22 2021 at 18:00):

That's okay. Thanks for getting it done!

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 22 2021 at 18:01):

Anyway, I have to jump, but as always, async updates, questions, &c are welcome.

view this post on Zulip BatmanAoD (Kyle Strand) (May 06 2021 at 17:35):

@WG-ffi-unwind hi all! Biweekly update time. Anything to mention? I don't think we have any impending deadlines, and I think we're all aware of the next steps for "C-unwind".

view this post on Zulip katelyn martin (May 06 2021 at 17:39):

view this post on Zulip nikomatsakis (May 06 2021 at 18:56):

sounds good to me, too

view this post on Zulip katelyn martin (May 20 2021 at 17:38):

Hi! Nothing exciting to report. I do have one question/request: I'd love to implement the abort-on-unwind wrappers. _But_, in previous conversations, I got the sense that this would be a bit of a new concept within the rustc codebase, which I'm frankly rather unfamiliar with in general.

Do any of you have a good idea who might be a good person to ask for more guidance, or design advice, for how to go about this work? It was especially helpful last time around having some signposts to help send me in the right direction. :blue_heart:

view this post on Zulip BatmanAoD (Kyle Strand) (May 20 2021 at 17:40):

Hey! Sorry, wasn't watching the clock for a bit.

view this post on Zulip BatmanAoD (Kyle Strand) (May 20 2021 at 17:45):

I...do not know, unfortunately. @nikomatsakis?

view this post on Zulip nikomatsakis (May 21 2021 at 15:01):

@katelyn martin I can hep you

view this post on Zulip nikomatsakis (May 21 2021 at 15:02):

let's open a topic on it

view this post on Zulip katelyn martin (Jun 03 2021 at 17:28):

Hello :wave: I come bearing unfortunate news.

I need to be honest with both myself and you all about my bandwidth at this time, and hand off the responsibilities of designing (_and most likely implementing_) abort-on-unwind wrappers for *-unwind functions. I had hoped I would be able to take this on, but time continues to pass and I do not want to be a blocker for stabilizing this exciting new feature.

I believe @Till Schneidereit is going to try and find someone that has the cycles to take this on, so I wanted to introduce you all in case you're unfamiliar. My apologies about this, I sincerely wish I had the time to take this work on :blue_heart:

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 03 2021 at 17:33):

Hi @katelyn martin ! I'm sorry to hear you won't be able to do the work you wanted to on this, but I'm glad to hear that you are narrowing your focus to the things you have the bandwidth for; that's more important than getting a feature stabilized sooner.

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 03 2021 at 17:35):

Thank you for introducing us to Till! I'm sorry we don't have someone ready to take on what you're handing off just yet (and admittedly I myself have only been contributing a minimal amount of time to the project for a while now).

view this post on Zulip nikomatsakis (Jun 04 2021 at 13:17):

Hey @katelyn martin -- thanks for all the work you did so far!

view this post on Zulip nikomatsakis (Jun 04 2021 at 13:17):

I'm sure we can find someone to pick it up

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 17:39):

@WG-ffi-unwind Hi everyone! (Sorry for the late start today.) Big thanks to @Alex Crichton for taking on the "next steps" work. He has a proposed approach in this PR, which has quite a bit of discussion: https://github.com/rust-lang/rust/pull/86155

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:40):

I was reading that PR

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 17:40):

Same; unfortunately I have not yet had time to really digest the conversation there.

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:40):

My personal take is that virtually any approach is fine as long as @Alex Crichton will see it through and we dn't get stuck half-way through

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:40):

I think the big diference now is we know where we are going

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:41):

(if it'd help I can give a summary of where that PR is at)

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:44):

@Alex Crichton sounds helpful :)

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:44):

Apart from fixing some known issues, there's one more major new piece of information worth pointing out, a proposed stabilization story, namely:

  1. Land this PR. This will change the codegen of extern "C" functions on panic=unwind to assume they might unwind. In other words we'll stop placing nounwind on things. This is to stem the tide of UB and remove a hole in Rust where the example I listed above is 100% safe code yet UB.
  2. Stabilize the extern "C-unwind" ABI. This allows any program using "C" today but wants to use unwinding to move to "C-unwind". At this point in time the "C" and "C-unwind" ABIs are effectively the same.
  3. After "C-unwind" is available on stable/beta/nightly, change the behavior of "C" back to placing nounwind everywhere and catching panics to then abort.

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:46):

Otherwise the PR is also having some back and forth with Ralf as I learn MIR and some of the intricacies. I implemented the bug fix as a MIR pass which is a relatively "destructive" pass in that it changes the operational semantics of the MIR. Ralf's thoughts are that we ideally don't want to do this (and if it we do we should explicitly list the "dialect" of the MIR), although I don't think this is implemented today (and there's other preexisting instances like drop elaboration which change the dialect)

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:47):

I dug in a bit and I found a comment which indicates to me that we probably don't want to change the construction of the MIR (since it could have an affect on the borrowck semantics), so given that I think that we probably want a pass of some form and it's largely just a question of when the pass actually runs.

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:47):

I wrote some more specific questions here but those are probably best handled later rather than right here

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:47):

in terms of discussion here, though, the proposed stabilization story is probably the best to focus on

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:48):

oh also this PR removes #[unwind] and all support

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:52):

@Alex Crichton what was the bug fix?

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:52):

I saw some of that back and forth and was surprised that MIR was involved

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:53):

2 bug fixes:

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:53):

sorry that latter example is not easy to show in one line on zulip heh

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:54):

eventually, the plan would be for both of those to abort, right?

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:54):

and the point is that, for the 1st one, we want to have some UB-free semantics to expose on stable

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:54):

until we have a transition plan in place (C-unwind)

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:55):

I don't thnk I undersatnd how the second one aborts....

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:55):

is the assumpton that bar would actually panic!()?

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:55):

correct, yeah, on aborting on both

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:55):

oh and yeah assume that bar is way more complicated or does a C++ unwind

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:56):

the codegen today is incorrect where it adds nounwind to bar which is not true, and now the codegen no longer does that

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:56):

I ended up changing the MIR construction for this because I figured it was best to reflect the "cleanup & abort" in the MIR

view this post on Zulip Alex Crichton (Jun 17 2021 at 17:57):

er, not the actual construction of MIR, just shape of the MIR by the time it makes its way to codegen

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:59):

OK, so the idea is that when -Cpanic=abort, we actually manage the unwind case for a call to a C-unwind function and abort

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:59):

that all makes sense to me

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:59):

is this plan written up?

view this post on Zulip nikomatsakis (Jun 17 2021 at 17:59):

we should probably get FCP approval from the lang team and then just Get It Done

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:00):

Well, it's implied by the RFC, though the implementation details of course are not.

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:00):

I don't know that we even need FCP approval

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:00):

I know that this was mildly contentious before

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:00):

but it seems like a perfectly reasonable path to me

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:00):

I just think it should be documented on an issue in very clear terms

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:00):

I'm happy to do w/e, just lemme know what needs writing up and where

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:01):

is there anything controversial about the PR apart from the interim step of having no UB?

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:01):

(I was under the impression everything here was implied by the RFC as well, but I can write more technical docs for how this is implemented)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:01):

I don't think we need any approval to make this the "C-unwind" behavior. The only possibly-contentious part now, I think, is whether we want to temporarily remove the LLVM UB from "C".

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:01):

I don't think we need docs per se

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:01):

I think having a list on the tracking issue or whatever that is like

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:01):

Stages

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:01):

I think the "do it as a MIR pass" isn't fully resolved? Ralf would know more about his concerns in that respect I think

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:01):

Yes, that part seems to imply some wrinkles we weren't previously aware of.

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:01):

Ooh, wait

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:02):

Alex Crichton said:

I think the "do it as a MIR pass" isn't fully resolved? Ralf would know more about his concerns in that respect I think

ah, yes, +1

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:02):

but that's "just a review concern"

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:02):

lol ok then yeah I think then that there's no other controversial parts

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:03):

Stage Complete? Panic from within an extern "C" fn "C-unwind" ABI
Today :check: LLVM-UB nightly
With PR Rust-UB but not LLVM-UB nightly
With C-unwind stabilized Rust-UB but not LLVM-UB beta
After announcement LLVM-UB stable

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:03):

roughly this

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:03):

it doesn't quite capture the "panic=abort" behavior or something, but that's basically just a bug you are fixing, not a transition point

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:04):

yeah that looks right to me

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:04):

unstable/stable referring to whether the behavior change is released on stable?

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:05):

er, well, I meant actually whether C-unwind is available on stable

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:05):

That column header could probably just be "C-unwind" availability, and the entries would be nightly, nightly, beta, stable

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:05):

+!

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:06):

Maybe there needs to be a row for going from nightly, with feature enabled to nightly, on by default ?

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

I don't know what that means...

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

oh, I see

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

meh you can add a row if you want :)

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

I just want that documented somewhere in a tracking issue

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

so we can point people at where we are

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

or on the project-group repo

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

probably a good idea to add the row

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

eventually the final two rows would be after release numbers

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

hopefully not too far from now

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:07):

in fact, we could probably just ... predict them, right/

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:08):

i.e., we expect to be able to start stabilization proces quite quickly I think?

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:08):

seems plausible to me we could get C-unwind stabilized before next release

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:08):

I'm also wondering about the with C-unwind stabilized row: wouldn't we want to turn LLVM-UB back on once the feature hits beta?

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:08):

I would need to follow up with a separate PR to split the c_unwind feature into two feature gates, one for the ABI name and one for the behavior change

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:08):

(but that won't take long)

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:09):

what behavior change? I'm confused :)

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:09):

but ok

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:09):

behavior change for "C"?

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:09):

behavior change == "catch unwinds and abort"

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:09):

ok

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:09):

then yes, we should do that

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:09):

it'd be helpful to have distinct feature names anyway

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:09):

to talk about the phases

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:09):

nightly is now 1.55, so "C-unwind" could be in 1.55, and then we could make the behavior change in 1.57?

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:10):

right so if we have C_unwind_abi and C_unwind_abort (say)

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:10):

well anyway I was going to make some table but yes

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:10):

@BatmanAoD (Kyle Strand) would you be up to make a table on the project-ffi-unwind repo README or something showing The Plan?

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:11):

seems like we're in agreement, just need to document it

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:11):

I was thinking it'd be good for @Alex Crichton not to make it but to read somebody else's interpretation to be sure at least 2 people see it the same way :)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:11):

Yes, I'll ask follow-up questions if I need it

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:12):

(actually c_unwind_abi would never be a feature, we'd probably just have a stabilization PR that didn't gate "C-unwind" but continued to gate behavior)

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:15):

ok ok

view this post on Zulip nikomatsakis (Jun 17 2021 at 18:15):

that makes sense

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:17):

Sorry, I didn't quite follow that; does that mean there will not be separate feature flags after all?

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:17):

And I would have thought c_unwind_abi corresponded to the feature flag we already introduced.

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:18):

I think we can probably skip that step by just immediately stabilizing "C-unwind"

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:18):

feature(c_unwind) gates two things today, the ABI and the behavior change, and we could just stabilize half of that and leave the other half undisturbed

view this post on Zulip Alex Crichton (Jun 17 2021 at 18:19):

but that's just a thought, we could also go the full split-the-feature-gates-then-stabilize-one-gate route too

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 17 2021 at 18:27):

Ah, okay, I see what you're saying.

view this post on Zulip BatmanAoD (Kyle Strand) (Jul 01 2021 at 17:40):

@WG-ffi-unwind Hey all, it sounds like Alex's PR is moving along (thanks again, and thanks to Niko for jumping in on review duty). I'll write a quick update for the lang team meeting next week. I don't believe we have any other items to discuss that aren't already being discussed in other channels.

view this post on Zulip BatmanAoD (Kyle Strand) (Jul 29 2021 at 17:38):

@WG-ffi-unwind Hi all, do we have any updates today?

view this post on Zulip nikomatsakis (Jul 30 2021 at 11:58):

I don't :) I'll be on vacation next 2 weeks

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 05 2021 at 00:01):

PR merged! Congrats @Amanieu, and thanks again for taking that bit on!

view this post on Zulip Alex Crichton (Aug 05 2021 at 00:02):

:+1:

As a reminder this is a change on stable Rust such that nounwind is no longer applied or inferred for extern "C" function pointers, pending the stabilization of the C-unwind ABI itself

view this post on Zulip Alex Crichton (Aug 05 2021 at 00:02):

I would consider it pretty unlikely that this entirely flies under the radar

view this post on Zulip simulacrum (Aug 05 2021 at 00:26):

Has someone drafted some language for the release notes (and marked the PR relnotes) in terms of what the change is meant to do and what users should do (if anything) to prepare for stabilization?

Would be great to get that in a comment on the PR or so.

view this post on Zulip Alex Crichton (Aug 05 2021 at 00:27):

I'd be happy to write that up and do so, is the PR itself the best location to place that information?

view this post on Zulip simulacrum (Aug 05 2021 at 00:36):

I think yeah, just a comment and tagging with relnotes should be quite fine

view this post on Zulip simulacrum (Aug 05 2021 at 00:36):

it'll go into a not-yet-drafted release notes (for 1.56) so it's a ways off that it's actually needed

view this post on Zulip Alex Crichton (Aug 05 2021 at 00:48):

ok! I'll leave a comment tomorrow and make sure the tag is there

view this post on Zulip Alex Crichton (Aug 05 2021 at 14:18):

comment written

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 12 2021 at 17:50):

@WG-ffi-unwind biweekly update - Alex's PR has been merged, and it looks like we're at least on the right path toward stabilization. If I understand correctly, @RalfJ may have some remaining soundness concerns, which we should continue discussing in #project-ffi-unwind > PR #86155. I think the next step is to write a blog post encouraging people to try out the feature on nightly; does that sound reasonable?

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 12 2021 at 18:13):

I believe this PR from @bjorn3 shows a path for resolving @RalfJ's concerns, but it does not yet handle Windows: https://github.com/rust-lang/rust/pull/86801

view this post on Zulip Alex Crichton (Aug 12 2021 at 18:38):

AFAIK there are two remaining unsoundness issues with C-unwind which I think prevent stabilization:

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 12 2021 at 18:43):

Thank you; looks like I overlooked that comment.

view this post on Zulip RalfJ (Aug 13 2021 at 09:30):

my concerns were mostly around the precise MIR semantics, which is tracked at #86299

view this post on Zulip RalfJ (Aug 13 2021 at 09:31):

Separate compilation of panic=unwind/panic=abort addressed with https://github.com/rust-lang/rust/pull/86801

Once that lands, do parts of what your new pass does become redundant or is it worth keeping them both?

view this post on Zulip RalfJ (Aug 13 2021 at 09:32):

Using -Clto -Cpanic=abort - there is no proposed fix for this yet

I think we have to get rid of that special pass that removes all landing pads -- it's fundamentally based on assumptions that do not hold any more.

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 13 2021 at 14:29):

I think we have to get rid of that special pass that removes all landing pads -- it's fundamentally based on assumptions that do not hold any more.

Is this an optimization that (in theory) LLVM could do during LTO, if it can prove everything in the call stack is nounwind? Since LLVM handles C++ as well, I think that would be a reasonable place for such an optimization to be implemented (if indeed it gives a significant benefit).

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 13 2021 at 14:30):

Thanks for the explanations.

view this post on Zulip RalfJ (Aug 14 2021 at 12:56):

I think this is something LLVM could/should do on its own when appropriate, yes.

view this post on Zulip Alex Crichton (Aug 14 2021 at 18:06):

I think that even if #86801 lands we'll still want the pass I wrote, that PR is just patching up the case where you mix crates with panic types. While I agree with the theoretical assessment that -Clto -Cpanic=abort specialization just needs to be removed, that has a practical impact with no replacement for anyone relying on it today and I don't know what to do about that. I don't know if anyone actually is relying on it, and to what degree things would be broken if we removed the behavior.

LLVM already does everything related to removing landing pads, so I don't think there's anything else LLVM can do here. The problem is that there's just so many non-optimizable ways that we generate IR that unless we manually remove all invoke LLVM won't do it for us. One main culprit is indirect function calls which are done with invoke but LLVM can't prove that all input function pointers don't actually unwind, either because inlining doesn't happen enough or something like that

view this post on Zulip RalfJ (Aug 15 2021 at 11:42):

I think that even if #86801 lands we'll still want the pass I wrote, that PR is just patching up the case where you mix crates with panic types.

Why do you think it is still needed? Would be good to get that documented somewhere.

view this post on Zulip RalfJ (Aug 15 2021 at 11:44):

for the LTO thing... one way to find out would be to just try to see what happens when you remove it?

the optimization is simply wrong e.g. for the case where libstd generates a vtable (entries of which might unwind if they call an extern fn that unwinds), and then that vtable is used from a panic=abort crate.

view this post on Zulip RalfJ (Aug 15 2021 at 11:46):

if we want to keep this optimization correct we have to do something where in a panic=unwind crate, all calls to extern "C-unwind" functions go through some layer that is only "plugged in" when building a binary crate, and that ensures all unwinding is caught "at the boundary" (from FFI to Rust)

view this post on Zulip bjorn3 (Aug 15 2021 at 13:49):

the optimization is simply wrong e.g. for the case where libstd generates a vtable (entries of which might unwind if they call an extern fn that unwinds), and then that vtable is used from a panic=abort crate.

#86801 will cause the function that calls the extern fn to abort when trying to unwind past it.

view this post on Zulip bjorn3 (Aug 15 2021 at 13:50):

When trying to unwind past a function, it's personality function is executed. This PR makes the personality function abort, thus preventing any unwinding past rust functions.

view this post on Zulip RalfJ (Aug 15 2021 at 14:59):

well that sounds like we don't need the new MIR pass any more then, if we have to rely on this personality function approach anyway

view this post on Zulip bjorn3 (Aug 15 2021 at 15:26):

The MIR pass is still necessary for extern "C" with -Cpanic=unwind, as the personality function only aborts with -Cpanic=abort.

view this post on Zulip RalfJ (Aug 15 2021 at 16:22):

extern "C" must not unwind

view this post on Zulip RalfJ (Aug 15 2021 at 16:23):

oh you mean Rust exporting such a function? but still, it must not unwind

view this post on Zulip RalfJ (Aug 15 2021 at 16:24):

Rust could export an unwinding "C-unwind" though, not sure if or how that would make a problem (I dont understand the case you are saying where the pass would still be necessary)

view this post on Zulip bjorn3 (Aug 15 2021 at 16:25):

Ah, right. The MIR pass is just for -Cpanic=abort. I think it is still necessary though as with -Cpanic=abort there would normally be no unwinding information due to the nounwind flag and thus no personality function being called.

view this post on Zulip bjorn3 (Aug 15 2021 at 16:28):

Say you have

// rustflags: -Cpanic=abort
extern "C-unwind" {
    fn may_unwind();
}

fn call_may_unwind() {
    unsafe { may_unwind(); }
}

that would result in call_may_unwind having nounwind. This means that in the absence of a landingpad LLVM would be allowed to assume that may_unwind can't unwind either and thus mark it as nounwind. As call_may_unwind is nounwind and all functions called by it are, LLVM will probably skip the unwinding information generation.

view this post on Zulip bjorn3 (Aug 15 2021 at 16:35):

Yup, just confirmed that replacing the invoke with a call in call_may_unwind will result in LLVM omitting the personality function from the unwind info, leaving just enough for backtraces, but not enough for unwinding that doesn't skip call_may_unwind completely.

view this post on Zulip RalfJ (Aug 16 2021 at 07:51):

Ah, right. The MIR pass is just for -Cpanic=abort

It's also for defining extern "C" fn in Rust (and ensuring they do not unwind)

view this post on Zulip RalfJ (Aug 16 2021 at 07:53):

bjorn3 said:

Yup, just confirmed that replacing the invoke with a call in call_may_unwind will result in LLVM omitting the personality function from the unwind info, leaving just enough for backtraces, but not enough for unwinding that doesn't skip call_may_unwind completely.

but doesn't the LTO pass in question do a similar replacement, and thus cause the same problem?

view this post on Zulip bjorn3 (Aug 16 2021 at 15:48):

Yes, that is my understanding.

view this post on Zulip RalfJ (Aug 16 2021 at 17:56):

@bjorn3 now I am confused. First you said your PR (the one with the personalities) fixes the problem with the LTO pass; now you say that the LTO pass also has this problem, which would mean that your PR doesn't fix it?

view this post on Zulip bjorn3 (Aug 16 2021 at 18:22):

I got confused about the original problem statement. It does indeed not fix the problem for LTO with the landingpad removal pass. It does fix the problem without LTO or with LTO without the landingpad removal pass.

view this post on Zulip RalfJ (Aug 16 2021 at 19:35):

okay -- AFAIK the only problem with LTO is the landingpad removal pass, so essentially I think you are saying it doesnt help with our LTO problem

view this post on Zulip RalfJ (Aug 16 2021 at 19:36):

(but it does help with the "mixing crates with different -C panic" problem)

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 26 2021 at 17:49):

@WG-ffi-unwind Ah, sorry for not initiating the weekly meeting on time.

Are these check-ins still helpful/useful?

It looks like our current need is to figure out how to make -Clto -Cpanic=abort sound. @Alex Crichton, @RalfJ , and @bjorn3 , do you feel like the conversation here could be more productive in some way?

view this post on Zulip bjorn3 (Aug 26 2021 at 18:37):

Would it be possible to have a custom annotation at llvm ir level that indicates that an abort landingpad is necessary for callers of a certain function when -Cpanic=abort is used and then add this annotation for C and C-unwind functions? A custom llvm pass could then remove all landingpads, but introduce new, aborting, ones when such an annotation found.

view this post on Zulip Alex Crichton (Aug 26 2021 at 19:13):

FWIW I'm not personally actively working on the -Clto -Cpanic=abort, or the mixed panic/abort issue myself.

view this post on Zulip nikomatsakis (Aug 26 2021 at 19:54):

@BatmanAoD (Kyle Strand) I have to admit I have kind of "checked out" from these check-ins, but I do want to talk about converting this effort into a new-fangled lang team initiative, and taking stock of where we are generally

view this post on Zulip nikomatsakis (Aug 26 2021 at 19:54):

I've kind of lost the plot :)

view this post on Zulip nikomatsakis (Aug 26 2021 at 19:54):

maybe you can schedule some time at https://calendly.com/nikomatsakis for us to go over that?

view this post on Zulip RalfJ (Sep 01 2021 at 01:24):

It looks like our current need is to figure out how to make -Clto -Cpanic=abort sound.

that pass relies on a fundamentally incorrect assumption, so... not sure how much we even can do. do we have an assesment of the fallout if we were to remove this pass? I assume its mostly a code size thing.

view this post on Zulip RalfJ (Sep 01 2021 at 01:25):

the mixed panic/abort issue I think is fixed by @bjorn3's approach, but only if we can truly do that for all our unwinding-supporting targets. and then I wonder if we even still need the new MIR pass, it seems somewhat redundant with that personality function approach.

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:08):

@RalfJ what pass are you referring to specifically? I feel like I'm missing some context

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:10):

Alex Crichton said:

AFAIK there are two remaining unsoundness issues with C-unwind which I think prevent stabilization:

I see, I guess it's this

view this post on Zulip nikomatsakis (Sep 02 2021 at 18:30):

@BatmanAoD (Kyle Strand) and I had a quick meeting to summarize our understanding of the current state, notes here

view this post on Zulip RalfJ (Sep 04 2021 at 23:12):

nikomatsakis said:

RalfJ what pass are you referring to specifically? I feel like I'm missing some context

there is a pass enabled with panic=abort LTO builds that indiscriminately removes all landing pads

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 09 2021 at 17:50):

I don't have any update for this week; based on the responses from last week, I think Niko and I may need to figure out a different way to facilitate and monitor progress here, as I don't think the check-ins are terribly productive at the moment.


Last updated: Jan 26 2022 at 08:34 UTC