Stream: t-lang

Topic: FFI-unwind design meeting


Kyle Strand (Feb 22 2020 at 17:37, on Zulip):

@T-lang The project-FFI-unwind group has decided that we need to delay the design meeting that was scheduled for Monday, because we want to give the broader community at least a week or so of advance notice (so people can plan to attend if they're interested) and so that you and anyone interested in attending will have time to consider the proposals we're surfacing prior to the discussion.

Towards that end, we've prepared a blog post that will be ready to post as soon as we have settled on a date; please feel free to read it and start providing feedback/thoughts. https://github.com/rust-lang/project-ffi-unwind/blob/master/blogposts/inside-rust/01-announcement.md

Kyle Strand (Feb 22 2020 at 17:42, on Zulip):

For scheduling the meeting, I would like to make sure we pick a date when @acfoltzer, @nikomatsakis, @Amanieu , and I are all available, and preferably @gnzlbg , @Josh Triplett , @RalfJ , and @centril as well.

boats (Feb 23 2020 at 14:33, on Zulip):

Question: why is unwinding through a frame without running destructors undefined behavior?

RalfJ (Feb 23 2020 at 16:57, on Zulip):

it's not UB but it's unsound (so probably this is just imprecise terminology)

RalfJ (Feb 23 2020 at 16:57, on Zulip):

the reason it's unsound is e.g. that it can be used to violate the pin-drop guarantee

RalfJ (Feb 23 2020 at 16:59, on Zulip):

as for the meeting, better schedule without me as I am fairly busy -- I dont have high stakes in this (the only reason I am involved at all is that I think the current situation [unwinding being UB but us not inserting abort-on-panic shims] is bad and we should do literally anything else^^). once you found a time, if it works out I may join, but if it doesn't that's okay too.

Amanieu (Feb 23 2020 at 17:33, on Zulip):

This can happen when we emit LLVM nounwind attributes, which can cause destructors to be optimized away as dead code since LLVM assumes they are unreachable. Since this behavior depends on the optimization level, you will end up with a program that behaves differently depending on optimization, which is a clear sign of undefined behavior.

Kyle Strand (Feb 23 2020 at 19:14, on Zulip):

Since this behavior depends on the optimization level, you will end up with a program that behaves differently depending on optimization, which is a clear sign of undefined behavior.

Hm, I'm not sure that's UB, exactly. It does not appear to imply "literally anything can happen."

nagisa (Feb 23 2020 at 19:43, on Zulip):

unwinding through nounwind is UB and anything can bappen.

Kyle Strand (Feb 23 2020 at 21:01, on Zulip):

@nagisa Ah, right, yes; we discussed whether LLVM's spec might be overly-scrupulous in this regard, but in fact that is what it says.

Amanieu (Feb 23 2020 at 21:47, on Zulip):

@nagisa Is there an exception to this rule if there are no destructors in the frame you are unwinding? I strongly expect so, otherwise longjmp on Windows (which uses unwinding) would be UB.

Amanieu (Feb 23 2020 at 21:48, on Zulip):

(obviously you need uwtable for this to work, which is enabled by default on Windows)

nagisa (Feb 23 2020 at 21:48, on Zulip):

LLVM docs don’t mention any, but I imagine that there might be some platform-specific definedness. Everything on windows is unwinding after all. Including aborting etc. too

nagisa (Feb 23 2020 at 21:49, on Zulip):

Or it could be the case that frontends are expected to just never attach nounwind to anything when generating Windows code.

nagisa (Feb 23 2020 at 21:50, on Zulip):

not too sure which way it is.

RalfJ (Feb 24 2020 at 12:15, on Zulip):

@Amanieu that sounds like UB caused by incorrect nounwind, which is not the same as the original question

RalfJ (Feb 24 2020 at 12:16, on Zulip):

I think I saw statements by @gnzlbg that SJLJ "unwinding" on Windows is not considered "unwinding" for LLLVM nounwind... but I might misremember

nikomatsakis (Feb 24 2020 at 14:32, on Zulip):

OK, so, we're going to cancel the ffi-unwind design meeting today? I'll update the calendar, and here is a doodle for folks to try and schedule a follow-up: https://doodle.com/poll/d9xevh43spf6rx8n

(cc @acfoltzer @Amanieu @Kyle Strand @gnzlbg @Josh Triplett @centril on the doodle above.)

centril (Feb 24 2020 at 15:22, on Zulip):

@nikomatsakis is the meeting today cancelled then?

nikomatsakis (Feb 24 2020 at 15:26, on Zulip):

I think so, let me update the calendar

centril (Feb 24 2020 at 15:28, on Zulip):

cheers

acfoltzer (Feb 24 2020 at 16:01, on Zulip):

Thanks for the heads up!

boats (Feb 24 2020 at 16:26, on Zulip):

Thanks for clarifying about what the UB comment was referring to.

boats (Feb 24 2020 at 16:27, on Zulip):

I agree with Kyle Strand about the comment on optimization level implying UB - that just implies that its implementation defined behavior. Not disputing anything else said.

boats (Feb 24 2020 at 16:29, on Zulip):

Ralf's comment raises the generally interesting note that thanks to Pin (specifically pin_mut!) we now have to uphold at the language level certain guarantees about destructors running for objects on the stack

Amanieu (Feb 24 2020 at 16:41, on Zulip):

Our current consensus in the ffi-unwind group is that skipping destructors in any way is considered UB. This means that when using longjmp the user must ensure that they do not skip over frames with destructors.

nikomatsakis (Feb 24 2020 at 17:27, on Zulip):

I think it could be useful to clarify what "UB" refers to exactly -- I would say it is "Rust-level UB". In short, something that you must not do, because safe code (like rayon, etc) could be relying on destructors to run, and we wish to ensure that it is valid for unsafe code to do that. But @RalfJ mentioned the term "unsound", I feel like perhaps there is a slight difference in how folks are using terminology here.

Amanieu (Feb 24 2020 at 17:30, on Zulip):

@nikomatsakis There's also the fact that we emit nounwind attributes and LLVM says it's UB to unwind through those. I believe we should specify it as language-level UB, we can always relax it later if we want.

centril (Feb 24 2020 at 17:31, on Zulip):

I believe by "sound" we mean "for all inputs and machine states [derived from safe Rust], calling this [safe] function, or [safe] operations reachable from it, cannot cause an error condition in the Rust Abstract Machine (R-AM)"

centril (Feb 24 2020 at 17:33, on Zulip):

Probably throwing in "forall possible configurations of the abstract machine as allowed by unspecified behavior"

RalfJ (Feb 24 2020 at 17:34, on Zulip):

boats said:

Ralf's comment raises the generally interesting note that thanks to Pin (specifically pin_mut!) we now have to uphold at the language level certain guarantees about destructors running for objects on the stack

note that this is not new with pinning

RalfJ (Feb 24 2020 at 17:34, on Zulip):

rayon::join and other scoped thread impls already rely on destructors running for objects on the stack

RalfJ (Feb 24 2020 at 17:35, on Zulip):

nikomatsakis said:

I think it could be useful to clarify what "UB" refers to exactly -- I would say it is "Rust-level UB". In short, something that you must not do, because safe code (like rayon, etc) could be relying on destructors to run, and we wish to ensure that it is valid for unsafe code to do that. But RalfJ mentioned the term "unsound", I feel like perhaps there is a slight difference in how folks are using terminology here.

language-level UB is something that Miri would check for, something that is directly engraved in the definition of the Abstract Machine. I dont see any good reason to do that here.

RalfJ (Feb 24 2020 at 17:36, on Zulip):

maybe its "library-level UB", but then, unwinding and the stack are not a library. no idea what you mean by "Rust-level".

RalfJ (Feb 24 2020 at 17:36, on Zulip):

but also we are having two parallel discussions here -- one about nouwnind being UB, and one about popping stack frames without running destructors. those questions are not directly related, as far as I can see.

pnkfelix (Feb 24 2020 at 17:37, on Zulip):

there's probably some distinction to draw here, in terms of ensuring that this is stated as a Safety property rather than a Liveness property. I.e. something like "you cannot evaluate colder frames on the control stack without first evaluating destructors on the warmer frames." (cold/warm terminology is to avoid top-down/bottom-up stack presentation issues.)

RalfJ (Feb 24 2020 at 17:38, on Zulip):

centril said:

I believe by "sound" we mean "for all inputs and machine states [derived from safe Rust], calling this [safe] function, or [safe] operations reachable from it, cannot cause an error condition in the Rust Abstract Machine (R-AM)"

yeah, we have defined something like this in the UCG

RalfJ (Feb 24 2020 at 17:39, on Zulip):

the "destructors of stack frame" case is one where conceivably there could be a variant of Rust (with the same compiler as "normal" Rust!) where not running them is safely possible, that just makes rayon and stack pinning and some other things unsound. it's a bit like mempocalypse -- two patterns that could be sound separately, but are not sound in combination.

Amanieu (Feb 24 2020 at 17:47, on Zulip):

The main question that we are dealing with is actually "What happens if an FFI exception unwinds into Rust code". I don't think this is something that could be checked with Miri since it involves FFI.

Amanieu (Feb 24 2020 at 17:48, on Zulip):

Also popping stack frames without running destructors is what happens if you unwind through nounwind since LLVM optimized your destructors away.

Simon Sapin (Feb 25 2020 at 07:17, on Zulip):

Good point, that transmute is allowed even in generic contexts for a type parameter without ?Sized

RalfJ (Feb 26 2020 at 10:10, on Zulip):

Amanieu said:

The main question that we are dealing with is actually "What happens if an FFI exception unwinds into Rust code". I don't think this is something that could be checked with Miri since it involves FFI.

@boats specifically asked "why is unwinding through a frame without running destructors undefined behavior?", as far I was concerned that is the main question we have been talking about here

RalfJ (Feb 26 2020 at 10:10, on Zulip):

but there seemed to be a parallel discussion where some folks discussed a different question

RalfJ (Feb 26 2020 at 10:31, on Zulip):

Amanieu said:

Also popping stack frames without running destructors is what happens if you unwind through nounwind since LLVM optimized your destructors away.

that's IMO not a great way to look at this -- it's like saying "dereferencing a NULL ptr triggers a segfault". indeed that will often happen, but not always -- what actually happens is we have UB. and then the way the binary accidentally happens to behave is that it skips destructors, but of course anything else might happen.

RalfJ (Feb 26 2020 at 10:32, on Zulip):

IOW, this is my usual statements that it is meaningless to look at the behavior of the compiled program unless we know there is no UB. @Amanieu I keep giving responses like that to you, so I am wondering if you disagree with me about that view of UB?

Amanieu (Feb 26 2020 at 10:37, on Zulip):

Sorry, I guess I worded this poorly. Let me try to rephrase: there are 2 ways that I know of which can (in compiled programs) result in unwinding a frame without running its destructors, and both are UB. The first is longjmp, which is specified (in C++) to be UB if jumping of frames with destructors. The other is the LLVM nounwind attribute which says that any unwinding through this frame is UB.

Amanieu (Feb 26 2020 at 10:37, on Zulip):

So basically, there exists no well defined way of unwinding a frame without running its destructors.

RalfJ (Feb 26 2020 at 10:39, on Zulip):

I see, thanks.

RalfJ (Feb 26 2020 at 10:39, on Zulip):

I am not sure if "longjmp-across-frame-with-destructors is UB in C++" implies that it is UB in Rust -- in fact, I think that is part of the discussion

RalfJ (Feb 26 2020 at 10:39, on Zulip):

and also, there are other operations that do this, like pthread_cancel

RalfJ (Feb 26 2020 at 10:41, on Zulip):

RalfJ said:

I am not sure if "longjmp-across-frame-with-destructors is UB in C++" implies that it is UB in Rust -- in fact, I think that is part of the discussion

on this point, I wonder why it is UB, actually -- is that something compilers exploit for optimizations, or is it just that they didnt want to specify what happens? in the Abstract Machine, it doesnt seem too hard to say "it just removes the stack frame and its allocations, but doesnt run any destructors"

Amanieu (Feb 26 2020 at 10:43, on Zulip):

Because longjmp may or may not run destructors, depending on the target, optimization level, etc.

Amanieu (Feb 26 2020 at 10:44, on Zulip):

On windows it runs destructors, unless you use certain compiler options to say that extern "C" doesn't unwind, in which cases it optimizes the destructors away. On all other platforms longjmp doesn't run destructors.

Amanieu (Feb 26 2020 at 10:44, on Zulip):

^ This applies to Rust as well, but only on windows-msvc, not windows-gnu.

Amanieu (Feb 26 2020 at 10:45, on Zulip):

So basically it is a non-portable mess and the C++ guys just decided to make it UB.

Amanieu (Feb 26 2020 at 10:46, on Zulip):

pthread_cancel is a bit more magic: it tries to unwind at first, then if it finds a frame without unwind info it falls back to a longjmp.

RalfJ (Feb 26 2020 at 19:45, on Zulip):

Amanieu said:

So basically it is a non-portable mess and the C++ guys just decided to make it UB.

Ah, Windows making things messy, what a surprise. ;) Makes sense though.

nikomatsakis (Feb 27 2020 at 18:43, on Zulip):

My main take here is that I think we do want to make a statement that things like rayon which rely on destructors executing are valid bits of unsafe code. The term "sound" doesn't quite cover this, as it pertains specifically to what safe code can do, but (as we stated) this is more a matter of "unsafe composability". I don't know the right way for us to talk about this, but at minimum I think we can agree that Rust would want to have some kind of "default set" of rules regarding what unsafe code can and cannot do, and those those rules would permit rayon (and hence exclude unwinding a frame without executing destructors). I do think it'd be useful to be precise about these sorts of assumptions (i.e., what are the things we assume unsafe code can and cannot do) so that at some later date we might find a way for unsafe code to declare this and to allow distinct, incompatible sets.

nikomatsakis (Feb 27 2020 at 18:43, on Zulip):

So I was using terminology like "it is UB" to indicate "unsafe code should not do this" -- but I'm happy to have a different way to say it, I do feel that term is quite overloaded

RalfJ (Feb 28 2020 at 09:28, on Zulip):

I personally feel like soundness is a pretty good way to express this -- indeed soundness is about safe code, but the entire composability story is about safe code! the hard part is making sure that any way safe code could compose things is fine.

RalfJ (Feb 28 2020 at 09:29, on Zulip):

unsafe code composing things is not a useful thing to look at as that code can make mistake -- if there is UB then, was it the fault of the pieces or did unsafe code compose them wrong?
but if its safe code doing the composition, then we know for sure it must be the fault of one of the pieces.

RalfJ (Feb 28 2020 at 09:30, on Zulip):

so I think what we should do is explicitly bless some of these unsafely-implemented-safely-exposed patterns as sound (that would in some sense, be a normative decision), and have examples for what this makes unsound (but that would just be useful notes, does not have to be normative)

BatmanAoD (Kyle Strand) (Mar 02 2020 at 17:04, on Zulip):

@nikomatsakis @centril @Josh Triplett @acfoltzer Zoom? Amanieu and I are at https://mozilla.zoom.us/j/768231760

Amanieu (Mar 02 2020 at 17:33, on Zulip):

ping @nikomatsakis @centril @Josh Triplett @acfoltzer

Amanieu (Mar 02 2020 at 17:34, on Zulip):

Meeting started 30 minutes ago (and for some reason has disappeared from the lang team calendar)

BatmanAoD (Kyle Strand) (Mar 02 2020 at 17:54, on Zulip):

https://hackmd.io/@co99gvfFSISYrFm9r3Psgg/rykL_65EU

acfoltzer (Mar 02 2020 at 18:22, on Zulip):

hi, sorry about that. I never got a calendar invite so I was out running errands :(

acfoltzer (Mar 02 2020 at 18:23, on Zulip):

I assume I missed it all?

Amanieu (Mar 02 2020 at 18:42, on Zulip):

@acfoltzer We're still in the meeting, join up.

Amanieu (Mar 02 2020 at 18:45, on Zulip):

(Actually kyle had to leave to we just ended the meeting)

acfoltzer (Mar 02 2020 at 18:55, on Zulip):

Gah, sorry. Next time I'll preemptively block out the times I answer yes on the Doodle

Amanieu (Mar 02 2020 at 18:58, on Zulip):

I'm not sure what happened. Only me and Kyle attended the meeting.

Amanieu (Mar 02 2020 at 18:58, on Zulip):

There was an event for it on the lang team calendar, but it got removed before the meeting?

pnkfelix (Mar 02 2020 at 20:25, on Zulip):

I think @nikomatsakis has/had a event for this standing meeting , and removed it 5 hours ago or so because niko forgot that the previous ffi-unwind meeting had been postponed.

nikomatsakis (Mar 02 2020 at 20:27, on Zulip):

Hmm I didn't think we had selected a time for this meeting :)

nikomatsakis (Mar 02 2020 at 20:27, on Zulip):

I deleted the event for this week because lang team design meetings are usually chosen/announced with some notice

nikomatsakis (Mar 02 2020 at 20:27, on Zulip):

though I realize that I think we need to adopt the compiler-team like structure of an "off week"

nikomatsakis (Mar 02 2020 at 20:27, on Zulip):

because it's really hard to keep up the work needed to schedule things

nikomatsakis (Mar 02 2020 at 20:27, on Zulip):

but maybe I missed some messages or something, if so, sorry

pnkfelix (Mar 02 2020 at 20:28, on Zulip):

my inference from my email notices is that this meeting was originally scheduled for Feb 24th ?

pnkfelix (Mar 02 2020 at 20:28, on Zulip):

and then that was cancelled (for whatever reason)

pnkfelix (Mar 02 2020 at 20:29, on Zulip):

and I'm guessing that the people present inferred that it was impliclty rescheduled to this week? THough I don't quite see how that inference actually works out, since in the general case this slot would be filled...

pnkfelix (Mar 02 2020 at 20:29, on Zulip):

so, yeah, I was wrong to say "niko forgot ..."

pnkfelix (Mar 02 2020 at 20:30, on Zulip):

(unless there was indeed some explicit rescheduling that I overlooked.)

Amanieu (Mar 02 2020 at 20:31, on Zulip):

We did announce the date of the meeting in the blog post.

pnkfelix (Mar 02 2020 at 20:34, on Zulip):

okay yes, I can see that was a result of the conversation over here

nikomatsakis (Mar 02 2020 at 20:45, on Zulip):

this seems like a clear indication that we need a centralized process to schedule lang team meetings =)

nikomatsakis (Mar 02 2020 at 20:46, on Zulip):

e.g., I haven't caught up on that conversation yet

nikomatsakis (Mar 16 2020 at 13:57, on Zulip):

Hey all, we have the FFI-unwind design meeting today in ~2 hours -- I'm not sure yet if I will make it. I'm feeling kind of under the weather today. I'm going to rest up a bit more in any case.

nikomatsakis (Mar 16 2020 at 15:59, on Zulip):

Hey @T-lang -- Been resting and I think I'm feeling better -- I'll be there but prob 5 minutes late.

centril (Mar 16 2020 at 16:02, on Zulip):

https://blog.rust-lang.org/inside-rust/2020/02/27/ffi-unwind-design-meeting.html

Amanieu (Mar 16 2020 at 16:04, on Zulip):

https://hackmd.io/rG_5ksyCTuKsjks5cHONZQ

nikomatsakis (Mar 16 2020 at 16:12, on Zulip):

https://paper.dropbox.com/doc/ffi-unwind-design-meeting--AwTXTaBKAfAeJSG9IMPu0AawAg-Utb2e8ehhS42CYfDSj9h4

BatmanAoD (Kyle Strand) (Mar 16 2020 at 16:35, on Zulip):

Sorry my attention's so divided; I've got a couple things going on here

Amanieu (Mar 16 2020 at 16:40, on Zulip):

https://paper.dropbox.com/doc/ffi-unwind-2020-01-13--AwQLyPBsf9hfZRTS4tbXcI0MAg-agituL322N0qRsCbcnn7D

BatmanAoD (Kyle Strand) (Mar 16 2020 at 17:09, on Zulip):

Here are some relevant issues (there are probably more):

https://github.com/rust-lang/rust/issues/52652

https://github.com/rust-lang/rust/issues/47932

It is probably better to just open a new one as a "top level" FFI unwind tracker.

centril (Mar 16 2020 at 17:15, on Zulip):

(let's not do a straw poll on a GH issue though :slight_smile: )

BatmanAoD (Kyle Strand) (Mar 16 2020 at 17:25, on Zulip):

"rocket ship if you like proposal 2, confused face if you like proposal 3"

BatmanAoD (Kyle Strand) (Mar 16 2020 at 17:26, on Zulip):

IIRC the governance wg had a Loomio instance set up, didn't they? I haven't used it; does it provide polls?

centril (Mar 16 2020 at 17:28, on Zulip):

/me is generally not a fan of conducting design decisions by polls :slight_smile:

Amanieu (Mar 16 2020 at 17:38, on Zulip):

We've been stuck on this issue for a month with no progress. Both proposals have advantages and downsides, there's no clear winner. We have to make a decision somehow.

BatmanAoD (Kyle Strand) (Mar 16 2020 at 17:57, on Zulip):

I don't think the poll should be binding. I think it may be helpful to see which way, generally, people lean.

centril (Mar 16 2020 at 22:10, on Zulip):

How people lean is heavily dependent on who shows up to these sorts of polls; and at any rate, "we have to make a decision somehow" doesn't mean it's done by poll, but the lang team has to reach consensus somehow, yes.

centril (Mar 16 2020 at 22:17, on Zulip):

As for what proposal to go with, from my perspective, 1/2 are highly preferable as:

BatmanAoD (Kyle Strand) (Mar 17 2020 at 01:27, on Zulip):

I'm not sure it's a smaller change. Introducing a new semantic element to the language is a fairly large change.

BatmanAoD (Kyle Strand) (Mar 17 2020 at 01:28, on Zulip):

The function pointer concern can, of course, be addressed eventually, though not immediately, with function pointer annotations + a nounwind annotation

BatmanAoD (Kyle Strand) (Mar 17 2020 at 01:30, on Zulip):

For proposal 2, it's still the case that UB can be introduced by adopting panic=abort.

BatmanAoD (Kyle Strand) (Mar 17 2020 at 01:35, on Zulip):

I think I agree with the point about it being easier to change the mechanism in the future, but I'm not sure. Certainly I don't think proposal 3 would make it infeasible to make such a switch.

centril (Mar 17 2020 at 01:37, on Zulip):

It's a smaller change to how people write code today; certainly "C nounwind" as a new ABI is a larger change to the spec, but that's something else entirely. (Although since this is a modification of an existing ABI, it doesn't imply that much additional spec complexity really.) However, recovering the function pointer thing makes changed defaults into something more complicated, as we now have to route the annotations to the type system, rather than use the existing ABI syntax which the type system and the rest already work with. As for being able to introduce UB via panic=abort, that seems like a discussion re. 1 vs. 2, but the cases are fewer (I assume you refer to "Forced unwind with destructors" with Proposal 2, "C unwind" boundary, panic=abort ==> UB)

BatmanAoD (Kyle Strand) (Mar 17 2020 at 01:50, on Zulip):

I still don't follow: making the existing ABI spec "just work" certainly seems to me to be the smaller change to "how people write code".

centril (Mar 17 2020 at 01:54, on Zulip):

It invalidates less of people's existing knowledge; what you knew about extern "C" remains true, and there's this new thing extern "C unwind". Making the existing ABI spec "just work" would suggest that "how people write code" today is to write code with lots of UB.

Josh Triplett (Mar 17 2020 at 04:15, on Zulip):

You're assuming people start out with detailed knowledge of the semantics of Rust, as opposed to a working knowledge of what produces working code in practice.

centril (Mar 17 2020 at 05:50, on Zulip):

Not really. Working with unsafe code and FFI certainly requires some knowledge, but it's not very detailed. One merely has to consult https://doc.rust-lang.org/nightly/nomicon/ffi.html#ffi-and-panics to find out that its UB to find out that panicing across FFI boundaries is UB. I think that's a reasonable amount of required reading. Also, given that we have emitted nounwind since "always", it seems strange to say that this is "working code in practice" (and there's not a lot of evidence to suggest that people did accidentally cause UB).

Josh Triplett (Mar 17 2020 at 05:52, on Zulip):

When code works, people don't necessarily consult the spec to find out if it's supposed to work.

centril (Mar 17 2020 at 05:52, on Zulip):

Also, it's not really "just work"; perhaps when you write it, but then later you want to use panic=abort, and then it doesn't work; that's not particularly helpful towards maintainable software

Josh Triplett (Mar 17 2020 at 05:53, on Zulip):

The status quo is "it works". There's value in not breaking that status quo.

Josh Triplett (Mar 17 2020 at 05:54, on Zulip):

(Also, we've had this conversation before, and repeating it seems unlikely to be productive. Suffice it to say that I value existing code even if it contains spec-UB.)

centril (Mar 17 2020 at 05:55, on Zulip):

Writing unsafe code with "when code works" in mind is going to become a problem fast -- it's not a good idea to reason about Rust via e.g. what the generated assembly is

BatmanAoD (Kyle Strand) (Mar 17 2020 at 18:54, on Zulip):

centril said:

Also, given that we have emitted nounwind since "always", it seems strange to say that this is "working code in practice" (and there's not a lot of evidence to suggest that people did accidentally cause UB).

This feels like a return to the conversations we've had in the past about what the actual use cases "in the wild" are. I may be misremembering, but I thought we had _not_ always emitted nounwind. Also, we have discussed serveral examples of projects using cross-language unwinding, which is in fact accidental UB.

BatmanAoD (Kyle Strand) (Mar 17 2020 at 18:54, on Zulip):

...well, I suppose "accidental" may not be accurate, except in the case of mozjpeg, where it does appear that the author expected unwinding to be well-behaved.

centril (Mar 18 2020 at 11:14, on Zulip):

@BatmanAoD (Kyle Strand) There are a few examples of accidental UB, and there are a few cases of intentionally ignoring UB. A few cases is not a statistically significant "this would do widespread ecosystem damage".
As for whether we've really always emitted nounwind, we have done so for a long time, which makes the difference moot for me.

Amanieu (Mar 18 2020 at 17:21, on Zulip):

I'm happy with either proposal, but have a very slight preference for proposal 2.

Last update: Jun 05 2020 at 22:45UTC