Stream: wg-ffi-unwind

Topic: meeting time


nikomatsakis (Oct 10 2019 at 00:39, on Zulip):

I forget, @WG-ffi-unwind, did we plan on having another meeting? And if so, when? I remember we said that @Kyle Strand was going to prep a new RFC, based on the outline we had prepared?

Kyle Strand (Oct 10 2019 at 01:02, on Zulip):

I think it might be appropriate to announce the group before drafting the new RFC. I suppose we can also submit the actual RFC PR in a WIP state like I did for 2753, though.

Kyle Strand (Oct 10 2019 at 01:02, on Zulip):

I don't think we had specific meeting plans.

nikomatsakis (Oct 10 2019 at 13:09, on Zulip):

I'm fine either way. I envisioned the RFC as "proposing" the group, so it kind of doubles as an announcement, but I think we could also post something on the Inside Rust blog. Could probably adapt my post.

nikomatsakis (Oct 10 2019 at 13:09, on Zulip):

I'd mostly like to have a set of steps we are following, because I'm feeling a bit lost as to what is happening

Adam C. Foltzer (Oct 10 2019 at 16:28, on Zulip):

I'm a bit lost as well, but the primary cause is I've been dragged away to work on other things all week. However, some of that has been relevant, like chatting with @Alex Crichton about unwinding generally. maybe we should have a Zulip meeting to get realigned?

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

Well, the repo now has a set of steps to take - I just haven't made any progress on them.

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

Maybe they need to be more concrete?

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

Current action items

  1. Make a draft charter for the project
    * "enable stable unwinding across FFI boundaries"

  2. Create a Zulip channel (need Niko or another Zulip admin to do this, I think)

  3. Close RFCs #2753 and #2699 and point to this repository and the Zulip channel
  4. Create design documents and drafts in this repo

    • create a "sketch" document to start, fill it in over time
  5. Create issues for the outstanding concerns

    • lock issues that are not the current focus topic?
    • unsafe code guidelines just used "focus" labels, maybe do that
    • or maybe use time-based issues (woah!) where the sync meeting marks a
      "pause" to collect, incorporate new findings, and set new topics
Kyle Strand (Oct 10 2019 at 18:46, on Zulip):

I think we can even cross the first one off

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

@nikomatsakis Sounds like we don't really have an update this week; should I skip the lang team call?

nikomatsakis (Oct 10 2019 at 20:21, on Zulip):

This seems good

nikomatsakis (Oct 10 2019 at 20:22, on Zulip):

I think we should do a zulip meeting, yeah

nikomatsakis (Oct 10 2019 at 20:22, on Zulip):

It probably makes sense to make a kind of regular-ish meeting time?

nikomatsakis (Oct 10 2019 at 20:22, on Zulip):

At least until we feel like things are progressing?

nikomatsakis (Oct 10 2019 at 20:29, on Zulip):

Have you started poking at the newer RFC text at all, @Kyle Strand ?

Kyle Strand (Oct 10 2019 at 20:44, on Zulip):

I have not, sorry. I did look at the draft in the repo and see that the RFC summary matched the notes you had written up last time we talked synchronously

Adam C. Foltzer (Oct 10 2019 at 20:46, on Zulip):

that sounds good to me; I am fine with continuing to meet on Thursday mornings, but am fairly open if y'all would prefer something else

Kyle Strand (Oct 10 2019 at 20:47, on Zulip):

Wednesday might be good in case we want to execute an action item prior to checking in with the lang team.

Kyle Strand (Oct 10 2019 at 20:47, on Zulip):

Otherwise, maybe meeting _after_ the lang team meeting (like...right now?) would be better

nikomatsakis (Oct 11 2019 at 13:43, on Zulip):

OK @WG-ffi-unwind so I was taking a stab at trying to "organize" our roadmap in a way that could be easily understood. I'm curious what you think of the table in this hackmd -- I think this would eventually move to the repository's main README.

The idea would be that:

nikomatsakis (Oct 11 2019 at 13:44, on Zulip):

Also, @gnzlbg, are you in that alias above (and do you want to be?) :point_up: I think you can add yourself, but if not I can add you.

Kyle Strand (Oct 11 2019 at 16:35, on Zulip):

What is the difference between "unwind from X to Y" and "propagate X [unwind] through Y"? Are the rows starting with "propagate" just sub-cases of the rows starting with "unwind from"?

Kyle Strand (Oct 11 2019 at 16:36, on Zulip):

Also, I think we should just say "out of scope" rather than "likely never supported", just because AFAIK there's no intent to close off the possibility of extending what can be done to other platforms

nikomatsakis (Oct 11 2019 at 16:37, on Zulip):

"out of scope for foreseeable future" seems fine

nikomatsakis (Oct 11 2019 at 16:38, on Zulip):

What is the difference between "unwind from X to Y" and "propagate X [unwind] through Y"? Are the rows starting with "propagate" just sub-cases of the rows starting with "unwind from"?

maybe there is no difference

nikomatsakis (Oct 11 2019 at 20:20, on Zulip):

OK I prepared a PR sketching this out in more detail. @WG-ffi-unwind what do y'all think?

Adam C. Foltzer (Oct 11 2019 at 20:57, on Zulip):

this looks fantastic! (except I'm Adam not Alex :wink:)

Adam C. Foltzer (Oct 11 2019 at 21:11, on Zulip):

I left a few comments on the PR, but I'm overall very happy with this

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

what the heck

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

did I write Alex somewhere?

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

I'm too used to Alex Crichton

Adam C. Foltzer (Oct 11 2019 at 21:18, on Zulip):

hehe, I figured :) it's at the top of the readme, not in that PR though

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

ok ok

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

applied your edits

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

ps, in the future, you can make "suggestions" where you edit the line yourself in gh pretty easily

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

which then allows me to apply them very easily

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

"suggestions" are my new favorite GitHub feature

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

https://help.github.com/en/articles/incorporating-feedback-in-your-pull-request

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

yeah, they're awesome

Kyle Strand (Oct 11 2019 at 21:25, on Zulip):

Looks like I was probably the one responsible for "Alex", even though I asked in advance if "Adam" was okay! Sorry!

Adam C. Foltzer (Oct 11 2019 at 21:25, on Zulip):

I must be missing the UI that allows that? maybe it's based on repo permissions?

Adam C. Foltzer (Oct 11 2019 at 21:25, on Zulip):

hah, no worries :)

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

I must be missing the UI that allows that? maybe it's based on repo permissions?

could be

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

I should probably add y'all as collaborators

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

but I'll hold off slightly, I plan to transfer this to rust-lang

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

and create a proper rust team

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

then I can give the permissions to that team, which is the new way to do things

Adam C. Foltzer (Oct 11 2019 at 21:26, on Zulip):

sounds good

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

anyway I'll merge that PR I think

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

woops, readme looks a bit funny, but basically good :)

Kyle Strand (Oct 11 2019 at 21:46, on Zulip):

I submitted a late review b/c it's mostly questions and other things that can be addressed in one or more future PRs

Kyle Strand (Oct 11 2019 at 21:47, on Zulip):

(Also b/c I had already written up the individual comments without noticing that you'd merged)

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

@Kyle Strand I left responses -- mostly I think your suggested changes are good, maybe open a PR?

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

one question is about my use of the term "undefiend behavior"

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

I don't really see the point of trying to find some other, more precise term.

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

but i'm not opposed if you have one in mind :)

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

at the end of the day though it seems like UB is..well.. what it is.

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

(not LLVM UB, to be clear)

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

(and it might be worth clarifying that difference)

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

gotta run

nikomatsakis (Oct 16 2019 at 10:03, on Zulip):

OK @WG-ffi-unwind -- we should setup a time for a brief sync. I'm feeling quite disorganized here. Previously we did Thu at 1pm and @Adam C. Foltzer you said that worked for you? I could work with that. Ideally it'd be 30 minutes. It has the advantage of coming shortly before the lang team meeting.

To clarify what I see as the purpose of this --

Kyle Strand (Oct 16 2019 at 16:37, on Zulip):

1pm in which time zone? One or two hours before the lang team meeting, right? I do want to continue to attend Release team meetings, so I'd like to avoid 11am-11:30am Mountain time. Those are pretty strictly timeboxed, though, so we could do 11:30am if we only need half an hour.

Kyle Strand (Oct 16 2019 at 16:37, on Zulip):

(I apologize if some or all of the "feeling disorganized" is on me!)

nikomatsakis (Oct 16 2019 at 16:40, on Zulip):

30 minutes should suffice

nikomatsakis (Oct 16 2019 at 16:40, on Zulip):

I meant 1pm in "US Eastern time"

nikomatsakis (Oct 16 2019 at 16:40, on Zulip):

So maybe 13:30 US Eastern time?

Adam C. Foltzer (Oct 16 2019 at 18:41, on Zulip):

I am down for 17:30 UTC :wink:

Adam C. Foltzer (Oct 16 2019 at 18:42, on Zulip):

pasted image

Adam C. Foltzer (Oct 16 2019 at 18:42, on Zulip):

I have a huge backlog on messages in this stream, which I will try to burn through this afternoon

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

I don't like to use UTC as my point of reference because I want it to track US Daylight Savings time :)

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

(which, at least for now, still aligns with most of Europe, apart from a few weeks in the year -- though I guess that may change...)

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

but yeah :) helpful

Adam C. Foltzer (Oct 16 2019 at 20:16, on Zulip):

yeah, I was just being a smartass, don't mind me. time zones are hard

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

OK I'm going to create an entry on the lang team calendar

nikomatsakis (Oct 16 2019 at 20:19, on Zulip):

I don't see this group being one that requires a lot of compiler interaction, so it seems "more" just lang

nikomatsakis (Oct 16 2019 at 20:19, on Zulip):

maybe those should just be one calendar

nikomatsakis (Oct 16 2019 at 20:19, on Zulip):

anyway

nikomatsakis (Oct 16 2019 at 20:20, on Zulip):

Event published

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

@all (that just notifies wg-ffi-unwind participants, correct?) - did we have a Zoom link?

nikomatsakis (Oct 17 2019 at 17:34, on Zulip):

Mm I thnk you want @WG-ffi-unwind =)

nikomatsakis (Oct 17 2019 at 17:34, on Zulip):

I was figuring we'd do the meeting on Zulip

nikomatsakis (Oct 17 2019 at 17:35, on Zulip):

But we could do Zoom if desired

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

the help pop-up did say "channel", not... whatever rust-lang is (edit: I wanted @stream)

acfoltzer (Oct 17 2019 at 17:35, on Zulip):

Zulip works for me

nikomatsakis (Oct 17 2019 at 17:35, on Zulip):

Should we start with some brief updates?

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

Yes please, seems like there's been a lot

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

It has been active!

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

OK, so, first off -- @gnzlbg and I seem to have hammered out terminology we are both happy with

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

In particular:

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

basically refers to a "panic" in the "virtual machine" that executes rust, so to speak

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

Side question: that seems a bit counter-intuitive to me, so I'm guessing I don't quite understand what that means.

nikomatsakis (Oct 17 2019 at 17:37, on Zulip):
Kyle Strand (Oct 17 2019 at 17:37, on Zulip):

I think of "panic" as being always well-defined

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

maybe best is to just check the page that we updated

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

I am currently reviewing

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

the tricky and somewhat subtle bit is that both undefined behavior and unspecified behavior ultimately have somewhat arbitrary results :)

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

^ yes

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

for our purposes, though, I think we're largely dealing with unspecified behavior

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

Agreed

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

Or, ought to be

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

the one final bit is that we settled on the term To Be Defined

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

to refer to behavior that is currently unspecified

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

but which this group expects to specify :)

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

so e.g. we might say that certain aspects of how a Rust panic propagates across a "C unwind" are TBD

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

or whatever

nikomatsakis (Oct 17 2019 at 17:40, on Zulip):

finally, I wrote up a document outlining the tradeoffs around exposing TBD behavior on stable, and I think at this point we all agree it (can) make sense to do so

nikomatsakis (Oct 17 2019 at 17:41, on Zulip):

I think that's something we should double check at the lang team meeting, but my understanding was that this was something that we all agreed made sense

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

for "official" purposes, all TBD behavior is simply unspecified.

Would it be reasonable to explicitly say in this documentation: whenever new "TBD" functionality hits stable, it will be considered "unspecified"?

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

I.e. in some official capacity, such as the Reference

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

Would it be reasonable to explicitly say in this documentation: whenever new "TBD" functionality hits stable, it will be considered "unspecified"?

I did say that

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

This designation is not part of the "Rust reference" -- for "official" purposes, all TBD behavior is simply unspecified.

acfoltzer (Oct 17 2019 at 17:44, on Zulip):

these look great; in particular the distinctions between UB/LLVM-UB and unspecified/TBD get to the heart of a lot of the miscommunications I've seen as we've discussed this topic

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

the other major developiment is that we have two distinct takes on the "0th" RFC ;)

acfoltzer (Oct 17 2019 at 17:44, on Zulip):

(seen/been a culprit of :wink:)

nikomatsakis (Oct 17 2019 at 17:45, on Zulip):

I wrote a fairly minimal one, and @gnzlbg has a somewhat more expansive one. To be honest they're not that far apart, and I'll probably just try to steal a lot of their text -- it's basically making more promises than mine.

nikomatsakis (Oct 17 2019 at 17:45, on Zulip):

I mostly didn't do that because I was being careful

nikomatsakis (Oct 17 2019 at 17:45, on Zulip):

I don't quite know how many "unknown unknowns" there are...

nikomatsakis (Oct 17 2019 at 17:45, on Zulip):

at some point maybe I'll actually read the itanium spec ;)

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

My only concern with more promises is that I got the sense that the lang team (especially Centril, I think) would prefer fewer promises wherever possible

acfoltzer (Oct 17 2019 at 17:46, on Zulip):

I still haven't had time to do a careful reading, but am I correct in surmising that @gnzlbg's version commits us to being 100% compliant with the ABI?

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

And I think that's generally reasonable

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

"the ABI"?

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

I'm also quite comfortable starting with the minimal one -- we'll add syntax, but we're not specifying any of the details yet -- and then do a follow-up that just talks about (e.g.) specifying linux

acfoltzer (Oct 17 2019 at 17:47, on Zulip):

with the expectation that if the Rust panic mechanism ever changes, that we'll add shims to translate? sorry, the native unwinding ABI (eg DWARF/Itanium on SysV)

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

oh, yes.

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

my version also does.

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

I think everybody is on board with that (including @Josh Triplett, from our conversations)

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

my version also does.

well, sort of -- mine says that once we specify a given platform, we have to stick to it :)

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

and notes that this means that if we diverge our rust impl from the native one, the main thing we must do is provide some sort of bridge

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

my main concern there is how that compatibility is scoped. if we're just saying that Rust unwinds with an ABI-compliant exception type using the system unwinding methods, I think that's fine because that's the implementation that exists today with #[unwind(allowed)]. however I would want to be clear that we are not fully ABI compliant until Rust treats foreign exceptions appropriately, which today it does not

acfoltzer (Oct 17 2019 at 17:50, on Zulip):

looking at the text now to see if this has already been addressed

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

I think one thing that would be really helpful

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

first of all, I think we should narrow to one platform at a time

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

and I'd love it if we had an enumerate of the "knobs" we have to decide

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

e.g., if look at itanium or whatever to call this ABI

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

we are not fully ABI compliant until Rust treats foreign exceptions appropriately, which today it does not

I think independently of how this is specified (or not), it would be good to have some technical details on what the current implementation does. Would you feel comfortable writing those up somewhere? I have done a very small amount of testing and not noticed anything outright barbarous in Rust's behavior :D

nikomatsakis (Oct 17 2019 at 17:52, on Zulip):

presumably, when a rust panic propagates, it has to "present itself" in various ways -- some kind of metadata, a string, whatever

nikomatsakis (Oct 17 2019 at 17:52, on Zulip):

I'd sort of like to see that stuff enumerated out

nikomatsakis (Oct 17 2019 at 17:53, on Zulip):

I think independently of how this is specified (or not), it would be good to have some technical details on what the current implementation does.

Yes, double this. That said, when I talked to @Alex Crichton about this, it seemed like there were lots of complexities. It'd probably be good to try and narrow things down to individual platforms.

nikomatsakis (Oct 17 2019 at 17:53, on Zulip):

Also I wonder if we should subscribe @Alex Crichton to this stream -- I'm gonna do it :P

acfoltzer (Oct 17 2019 at 17:53, on Zulip):

most of it is only observable with catch_unwind, but yes

acfoltzer (Oct 17 2019 at 17:53, on Zulip):

I can help write up more about the gaps in the current implementation. I don't think they're very big

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

I'm gonna do it

Alex can unsubscribe if so desired!

Also, I suspect RalfJung may be interested, though I don't know so.

acfoltzer (Oct 17 2019 at 17:55, on Zulip):

from @gnzlbg's proposal:

whether such unwindings can always, sometimes, or never be caught with catch_unwind or not is target-dependent. If some of these unwindings that do not originate in Rust can be caught, their value is then of type std::panic::ForeignException (that is, the Result::Err(Any) that catch_unwind returns can be downcasted to such a type).

I am very skeptical about including this capability at any point, but particularly for a 0th RFC it feels like too much

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

Does std::panic::ForeignException already exist, or is that a proposed addition to std?

acfoltzer (Oct 17 2019 at 17:56, on Zulip):

proposed addition

nikomatsakis (Oct 17 2019 at 17:56, on Zulip):

oh yeah I definitely did expect to remove that

nikomatsakis (Oct 17 2019 at 17:56, on Zulip):

so I guess this is a good question

nikomatsakis (Oct 17 2019 at 17:56, on Zulip):

I think the only thing I did specify in my version was

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

Agreed, I think any suggestions for std features should be disqualified for RFC 0

nikomatsakis (Oct 17 2019 at 17:56, on Zulip):

if you do this:

acfoltzer (Oct 17 2019 at 17:56, on Zulip):

perhaps for 0th we should commit to being an ABI-compliant producer of exceptions, but not necessarily an ABI-compliant consumer

nikomatsakis (Oct 17 2019 at 17:57, on Zulip):
extern "C unwind" fn foo() { panic!("foo") }

fn bar() {
  foo();
}
nikomatsakis (Oct 17 2019 at 17:57, on Zulip):

it should interoperate as you expect

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

which basically means: if there is a C unwind ABI, then you must have some way to convert Rust to native and back again

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

not necessarily an ABI-compliant consumer

With the idea that we do at least expect Rust to be able to consume _its own_ panic objects, regardless of whether they traverse foreign frames

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

but we don't say what those ways are

acfoltzer (Oct 17 2019 at 17:59, on Zulip):

that sounds good. I just want to make sure we're not committing to doing anything sensible at all with foreign exceptions for the 0th RFC

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

ok well it's been 30 minutes but maybe this is something we can bring to alng team

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

the other thing is

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

I think for now we should structure ourselves as doing a series of RFCs

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

this is kind of what I proposed in my write-up

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

but I did write that we have the expectation that, once we open an RFC, it has been through quite some vetting already

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

so if you want to be involved in the more "formative phases", this group is the place to be

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

:+1:

acfoltzer (Oct 17 2019 at 18:00, on Zulip):

just a quick update on my stuff:
- shared the note about my availability for the next ~month
- trying to keep as up-to-date as possible with filling in details about Lucet use cases on Zulip
- read about half of the PRs, very few of the PR comments

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

Probably also worth mentioning the use of "unspecified behavior" and the formal definition thereof, which I think might be a good thing to adopt in the Reference as well

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

and to reiterate, I can make time for this but @ing me directly is a good way to make sure that I show up if my input is needed

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

(mentioning to the Lang team, that is, since it affects them)

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

Probably also worth mentioning the use of "unspecified behavior" and the formal definition thereof, which I think might be a good thing to adopt in the Reference as well

Yes. I think we should consider writing an RFC on this too -- just for the 'exposure'.

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

Agreed

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

@Kyle Strand do you plan to attend lang team mtg?

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

Yes

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

do you want to write up a bit of a summary with links to things?

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

just a few bullet points

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

Sure

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

thanks all

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

:wave:

acfoltzer (Oct 17 2019 at 18:02, on Zulip):

thank you all!

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

thanks for all your time, both of you!

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

"I'll give it right back to you one of these days" - Jimi

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

I am very skeptical about including this capability at any point, but particularly for a 0th RFC it feels like too much

We kind of need to be able to do this anyways, e.g., to properly implement catch_unwind, see: https://github.com/rust-lang/rust/issues/65441

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

@Amanieu said they also had other uses for this, maybe they can expand on those

acfoltzer (Oct 17 2019 at 18:18, on Zulip):

my understanding is that catch (...) blocks catching foreign exceptions in C++ is a feature that C++ folks regret

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

On Linux, <exception> allows things like catch (ada_exception const& e)

acfoltzer (Oct 17 2019 at 18:19, on Zulip):

I agree with @Amanieu in the linked thread:

I feel that we should simply let all foreign exceptions unwind through catch_unwind without catching them.

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

so its not only catch(...) blocks

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

If we say that unwinding with a foreign exception is UB, I think it would be a quality-of-implementation bug not to report a run-time error on UB in those platforms where we can do so

acfoltzer (Oct 17 2019 at 18:21, on Zulip):

for now I think it might fall in the "TBD" category, since I think it's within the scope of this group to eventually define what the behavior is

acfoltzer (Oct 17 2019 at 18:22, on Zulip):

I'm just sharing my personal inclination when I say that I don't think we should catch foreign exceptions in catch_unwind, but I'm happy to argue that at more length when we've reached that point in this project

acfoltzer (Oct 17 2019 at 18:24, on Zulip):

I'm definitely opposed for including it in the 0th RFC due to the standard library implications, as well as implementation complications that extend beyond just the compiler's behavior at FFI boundaries

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

- read about half of the PRs, very few of the PR comments

Do you feel adequately "caught up"? If not, do you have a sense of whether we're failing to capture some important stuff in the repo itself, or is it too early to tell?

(@acfoltzer )

Alex Crichton (Oct 17 2019 at 18:51, on Zulip):

:wave:

Don't have a chance right now to read up on the full discussion but if y'all need me feel free to ping me!

acfoltzer (Oct 17 2019 at 18:51, on Zulip):

my sense is that things are heading in the right direction. until I can free up some time to read it all I won't know for sure if anything is missing, but maybe the best way to do that would be to add me as a reviewer on the PR that emerges between #9 and #11?

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

for now I think it might fall in the "TBD" category, since I think it's within the scope of this group to eventually define what the behavior is

Note that RFC 0th says that it is not a goal of this group to define the behavior.

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

I'm definitely opposed for including it in the 0th RFC due to the standard library implications, as well as implementation complications that extend beyond just the compiler's behavior at FFI boundaries

This has been repeated a couple of times. What's the complication of adding something to the standard library? We do that all the time.

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

@acfoltzer ^^

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

Well, for the 0th RFC, we want to be so minimal that we do not need further bikeshedding. The ABI string "C unwind" is, I think, at that point; but a new std addition is not.

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

yeah, that's my sense as well regarding adding to the standard library, but I'm not experienced in the process of moving such things through

acfoltzer (Oct 17 2019 at 19:06, on Zulip):

for now I think it might fall in the "TBD" category, since I think it's within the scope of this group to eventually define what the behavior is

Note that RFC 0th says that it is not a goal of this group to define the behavior.

I hadn't seen this; I suppose this is the relevant part of #11?

acfoltzer (Oct 17 2019 at 19:07, on Zulip):

I'm fine with this split personally, as I think the issue you bring up in https://github.com/rust-lang/rust/issues/65441 would be addressed by the former point

acfoltzer (Oct 17 2019 at 19:09, on Zulip):

other than Katharina's talk from last year's RustConf, I'm unaware of anyone who's trying to actually catch foreign exceptions

acfoltzer (Oct 17 2019 at 19:10, on Zulip):

and while it's not a point that I'm personally too invested in, adding foreign exception handling to catch_unwind should raise some major red flags in terms of how it would constrain the Rust panic mechanism

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

Note that most of the complexity is introduced by allowing foreign exceptions to unwind through Rust

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

IIUC you are proposing to have catch_unwind not catch any foreign exceptions, but which behavior to pick there is not a complexity source

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

and while it's not a point that I'm personally too invested in, adding foreign exception handling to catch_unwind should raise some major red flags in terms of how it would constrain the Rust panic mechanism

As I see it, it does not. It would just mean that catch_unwind needs to support both

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

But they can be independent

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

Maybe it would be better to attack the problem of catching foreign exceptions using a different API (e.g. catch_foreign_exception(|| ...) or similar - that's something I might be on board with

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

but at that point we are just talking syntax, because the real issue is how to support foreign exceptions in the first place

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

and all the perils mentioned for catch_unwind in the RFC would still apply, that is, catch_foreign_exception might catch all, some, or none, of the foreign exceptions, depending on the platform

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

other than Katharina's talk from last year's RustConf, I'm unaware of anyone who's trying to actually catch foreign exceptions

If you want to spawn a thread that does a computation that might throw a foreign exception, without a way to catch them, they bring down your whole application

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

So you need to at least shim your computation in some foreign code that allows you to catch the exception to prevent that - or use a process or something like that.

acfoltzer (Oct 17 2019 at 19:23, on Zulip):

with this many unresolved questions, doesn't it make sense to not try tackling this for the 0th RFC?

acfoltzer (Oct 17 2019 at 19:24, on Zulip):

or, put differently, what is the harm that you see coming if we do not have this in the 0th RFC?

Josh Triplett (Oct 17 2019 at 19:24, on Zulip):

None of that sounds like the original problem the working group set out to solve.

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

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

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

The 0-th RFC now says that "C unwind" is not guaranteed to implement the platform ABI, but that we intend to do so. The 1-th RFC might say that we only implement the produce part. The 2-th RFC the consume part, but maybe due to decisions in the 0-th RFC, we can't implement the consume part.

acfoltzer (Oct 17 2019 at 19:27, on Zulip):

if we changed "But not And perhaps to allow catching or throwing native exceptions from Rust code" would that help?

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

For me, this looks much more complex than just saying that we add "C unwind" on Linux only on RFC 1, and on Windows on RFC 2, and on Mac on RFC 3

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

Such an approach has less unknowns because we can verify at each step that the ABI actually works

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

Some systems ABIs allow things like foreign exceptions, I don't want the feature to land in a position where that cannot be supported

Josh Triplett (Oct 17 2019 at 19:30, on Zulip):

If we leave the propagation of foreign exceptions as UB, I don't see why we couldn't specify it later.

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

For example, what would we specify that to for targets for which unwinding does not make sense at all ?

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

that's kind of a consequence of adding "C unwind" to all targets in RFC 0, leaving everything as UB, and then worrying about targets later

acfoltzer (Oct 17 2019 at 19:33, on Zulip):

I think we're seeing things along different axes of complexity; I see way fewer design questions to answer and less implementation work to be done if we only consider the behavior of Rust exceptions as a first step. If the RFCs instead proceeded by having complete ABI interop, but on one platform at a time, that means we would have to frontload almost all of the design work for a complete solution

Josh Triplett (Oct 17 2019 at 19:33, on Zulip):

What do you mean by "what would we specify that to"?

Josh Triplett (Oct 17 2019 at 19:34, on Zulip):

We wouldn't specify it, that's the point.

Josh Triplett (Oct 17 2019 at 19:34, on Zulip):

If unwinding doesn't make sense, then why would we specify foreign exception unwinding?

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

So now we have added a language feature that says "C + unwinding" but that cannot be implemented meaningfully for a target

Josh Triplett (Oct 17 2019 at 19:35, on Zulip):

That's an interesting misinterpretation of what I said.

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

I don't think you understood what I said

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

Why would we add a language feature that's correct to use, has unspecified behavior, but cannot ever work ?

Josh Triplett (Oct 17 2019 at 19:36, on Zulip):

I think neither of us is understanding where the other is coming from. I'm about to board a plane, so I'll have to continue this another time.

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

It is not correct to use "C unwind" on a target that does not support unwinding.

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

RFC 0 does not say that

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

its says that it has unspecified behavior, and it emphasizes that it is not UB

Josh Triplett (Oct 17 2019 at 19:37, on Zulip):

It absolutely can work. Your assertion that it "cannot ever work" does not make sense to me.

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

One possible behavior is compiler-error.

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

Another is...whatever happens already when unwind(allowed) is used on such a platform.

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

"Unspecified" is specifically allowed to have a wide range of behaviors.

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

One possible behavior is compiler-error.

Is it? According to the definition we agreed on we said that it does something in the abstract machine, we just not say what it is.

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

And to change over time

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

For that to happen, it needs to compile.

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

That is a good point; @nikomatsakis what is your perspective on whether unspecified behavior "must compiler"?

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

If it is not required to compile, then I'd be in with it.

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

In any case, though, in previous RFC discussions we have agreed that "C unwind" would not be one of the cross-platform always-available ABIs

acfoltzer (Oct 17 2019 at 19:40, on Zulip):

so, we have two axes here I think:

  1. How rich is our support for the ABI?
  2. Which target triples are supported?
Josh Triplett (Oct 17 2019 at 19:40, on Zulip):

I certainly wouldn't expect it to be.

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

I thought so to as well, which is why I was surprised for RFC 0 not to mention it.

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

Note, too, that our roadmap started out with that platform-support table, with "not in scope" for all but Win/Mac/Linux

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

Well, it's just a draft; let's add it :D

acfoltzer (Oct 17 2019 at 19:41, on Zulip):

I don't expect that RFC 0 would commit to "C unwind" being available on any particular target triple, except maybe 64-bit Linux just to have an example case

Josh Triplett (Oct 17 2019 at 19:41, on Zulip):

(Also, please pardon my not being up to date on the terminological discussion regarding "UB" versus "unspecified".)

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

Well, it's just a draft; let's add it :D

I left a comment asking for clarification. I'll add it instead.

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

(Also, please pardon my not being up to date on the terminological discussion regarding "UB" versus "unspecified".)

@Josh Triplett Fortunately, we've written up a document in the repo, so at least we have a place to keep the "latest and greatest shared understanding"!

Josh Triplett (Oct 17 2019 at 19:43, on Zulip):

I'm aware; just haven't had a chance to read it. Still on vacation, about to get on a plane to Athens.

Josh Triplett (Oct 17 2019 at 19:43, on Zulip):

:)

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

I say before that I would be in if we can choose the unspecified behavior to not compile later on, that still holds, but I would prefer if we were not to add any code that would compile and that we later on need to prevent from compiling

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

But adding the "C unwind" on some platforms only should make sure that we only add it for those platforms for which we can actually implement it, so that should be fine

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

choose the unspecified behavior to not compile later on, that still holds, but I would prefer if we were not to add any code that would compile and that we later on need to prevent from compiling

That's a good point. And, I think, definitely a divergence from the C++ definition of "unspecified" (I will check).

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

Yeah, in that context, it's probably better to define "unspecified" as "compiles, but behavior may change, and for any two behaviors in the range of possibilities, the actual behavior can switch from one to the other at any time"

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

rather than trying to include a concept of monotonic-change in the definition, from does-not-compile to compiles, but not vice-versa

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

@nikomatsakis @acfoltzer It looks like I won't be able to meet tomorrow until after the lang team meeting.

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

I have a flight mid-day Friday, but it's conceivable I could chat while waiting for my plane....

acfoltzer (Oct 23 2019 at 20:19, on Zulip):

I won't be able to make it any later than the usual time tomorrow; I'm on Eastern time this week and my afternoon is pretty full. do we have a calendar event set up?

Kyle Strand (Oct 23 2019 at 20:29, on Zulip):

I am available for about three hours starting now, it turns out.

acfoltzer (Oct 23 2019 at 20:30, on Zulip):

not a good time for me, unfortunately. but I also haven't had time to do much on the project, so you shouldn't let that stop y'all :slight_smile:

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

That's reasonable! Hope your deliverable is going well

Last update: Nov 15 2019 at 11:05UTC